docs/master
view ch03.roff @ 20:7a100c80fa91
Some new text (show/mhshow; prompter).
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Sun, 06 May 2012 17:33:45 +0200 |
| parents | ab5253e48c74 |
| children | bb8a8be49024 |
line source
1 .H0 "Work Report
2 .P
3 foo
4 .P
5 bar
7 .H1 "Removal of Code Relicts
8 .P
9 The code base of mmh originates from the late 70s, had been extensively
10 worked on in the mid 80s, and had been partly reorganized and extended
11 in the 90s. Relicts of all those times had gathered in the code base.
12 My goal was to remove any ancient code parts. One part of the task was
13 converting obsolete code constructs to standard constructs, the other part
14 was dropping obsolete functions.
15 .P
16 As I'm not even thirty years old and have no more than seven years of
17 Unix experience, I needed to learn about the history in retroperspective.
18 Older people likely have used those ancient constructs themself
19 and have suffered from their incompatiblities and have longed for
20 standardization. Unfortunately, I have only read that others had done so.
21 This put me in a much more difficult positions when working on the old
22 code. I needed to recherche what other would have known by heart from
23 experience. All my programming experience comes from a time past ANSI C
24 and past POSIX. Although I knew about the times before, I took the
25 current state implicitely for granted most of the time.
26 .P
27 Being aware of
28 these facts, I rather let people with more historic experience solve the
29 task of converting the ancient code constructs to standardized ones.
30 Luckily, Lyndon Nerenberg focused on this task at the nmh project.
31 He converted large parts of the code to POSIX constructs, removing
32 the conditionals compilation for now standardized features.
33 I'm thankful for this task being solved. I only pulled the changes into
34 mmh.
35 .P
36 The other task \(en dropping ancient functionality to remove old code \(en
37 I did myself, though. My position to strip mmh to the bare minimum of
38 frequently used features is much more revolutional than the nmh community
39 likes it. Without the need to justify my decisions, I was able to quickly
40 remove functionality I considered ancient.
41 The need to discuss my decisions with
42 peers likely would have slowed this process down. Of course, I researched
43 if a particular feature really should be dropped. Having not had any
44 contact to this feature within my computer life was a first indicator to
45 drop it, but I also asked others and searched the literature for modern
46 usage of the feature. If it appeared to be truly ancient, I dropped it.
47 The reason for dropping is always part of the commit message in the
48 version control system. Thus, it is easy for others to check their
49 view on the topic with mine and possibly to argue for reinclusion.
51 .U2 "MMDF maildrop support
52 .P
53 I did drop any support for the MMDF maildrop format. This type of format
54 is conceptionally similar to the mbox format, but uses four bytes with
55 value 1 (\fL^A^A^A^A\fP) as message delimiter,
56 instead of the string ``\fLFrom\ \fP''.
57 Due to the similarity and mbox being the de-facto standard maildrop
58 format on Unix, but also due to the larger influence of Sendmail than MMDF,
59 the MMDF maildrop format had vanished.
60 .P
61 The simplifications within the code were only moderate. Switches could
62 be removed from tools like
63 .L packf ,
64 which generate packed mailboxes. Only one packed mailbox format remained:
65 mbox.
66 The most important changes affect the equally named mail parsing routine in
67 .L sbr/m_getfld.c .
68 The direct MMDF code had been removed, but as now only one packed mailbox
69 format is left, code structure simplifications are likely possible.
70 The reason why they are still outstanding is the heavily optimized code
71 of
72 .Fu m_getfld() .
73 Changes beyond a small local scope \(en
74 which restructuring in its core is \(en cause a high risk of damaging
75 the intricate workings of the optimized code. This problem is know
76 to the developers of nmh, too. They also avoid touching this minefield
77 if possible.
79 .U2 "UUCP Bang Paths
80 .P
81 More questionably than the former topic is the removal of support for the
82 UUCP bang path address style. However, the user may translate the bang
83 paths on retrieval to Internet addresses and the other way on posting
84 messages. The former can be done my an MDA like procmail; the latter
85 by a sendmail wrapper. This would ensure that any address handling would
86 work as expected. However, it might just work well without any
87 such modifications, as mmh does not touch addresses much, in general.
88 But I can't ensure as I have never used an environment with bang paths.
89 Also, the behavior might break at any point in further development.
91 .U2 "Hardcopy terminal support
92 .P
93 More of a funny anecdote is the remaining of a check for printing to a
94 hardcopy terminal until Spring 2012, when I finally removed it.
95 I surely would be very happy to see such a terminal in action, maybe
96 actually being able to work on it, but I fear my chances are null.
97 .P
98 The check only prevented a pager to be placed between the outputting
99 program (\c
100 .Pn mhl )
101 and the terminal. This could have been ensured with
102 the
103 .Sw \-nomoreproc
104 at the command line statically, too.
106 .U2 "Removed support for header fields
107 .P
108 The `Encrypted' header had been introduced by RFC\^822, but already
109 marked legacy in RFC 2822. It was superseded by FIXME.
110 Mmh does no more support this header.
111 .P
112 `Content-MD5' headers were introduced by RFC\^1864. They provide only
113 a verification of data corruption during the transfer. By no means can
114 they ensure verbatim end-to-end delivery of the contents. This is clearly
115 stated in the RFC. The proper approach to provide verificationability
116 of content in an end-to-end relationship is the use of digital cryptography
117 (RFCs FIXME). On the other hand, transfer protocols should ensure the
118 integrity of the transmission. In combinations these two approaches
119 make the `Content-MD5' header field useless. In consequence, I removed
120 the support for it. By this removal, MD5 computation is not needed
121 anywhere in mmh. Hence, over 500 lines of code were removed by this one
122 change. Even if the `Content-MD5' header field is useful sometimes,
123 I value its usefulnes less than the improvement in maintainability, caused
124 by the removal.
126 .U2 "Prompter's Control Keys
127 .P
128 The program
129 .Pn prompter
130 queries the user to fill in a message form. When used by
131 .Pn comp
132 as:
133 .DS
134 comp \-editor prompter
135 .DE
136 the resulting behavior is similar to
137 .Pn mailx .
138 Appearently,
139 .Pn prompter
140 hadn't been touched lately. Otherwise it's hardly explainable why it
141 still offered the switches
142 .Sn \-erase \fUchr\fP
143 and
144 .Sn \-kill \fUchr\fP
145 to name the characters for command line editing.
146 The times when this had been neccessary are long time gone.
147 Today these things work out-of-the-box, and if not, are configured
148 with the standard tool
149 .Pn stty .
152 .H1 "Draft and Trash Folders
153 .U2 "Draft Folder
154 .P
155 Historically, MH provided exactly one draft message, named
156 .Fn draft
157 and
158 being located in the MH directory. When starting to compose another message
159 before the former one was sent, the user had been questioned wether to use,
160 refile or replace the old draft. Working on multiple drafts at the same time
161 was impossible. One could only work on them in alteration by refiling the
162 previous one to some directory and fetching some other one for reediting.
163 This manual draft management needed to be done each time the user wanted
164 to switch between editing one draft to editing another.
165 .P
166 To allow true parallel editing of drafts, in a straight forward way, the
167 draft folder facility exists. It had been introduced already in July 1984
168 by Marshall T. Rose. The facility was deactivated by default.
169 Even in nmh, the draft folder facility remained deactivated by default.
170 At least, Richard Coleman added the man page
171 .Mp mh-draft(5)
172 to document
173 the feature well.
174 .P
175 The only advantage of not using the draft folder facility is the static
176 name of the draft file. This could be an issue for MH frontends like mh-e.
177 But as they likely want to provide working on multiple drafts in parallel,
178 the issue is only concerning compatibility. The aim of nmh to stay compatible
179 prevented the default activation of the draft folder facility.
180 .P
181 On the other hand, a draft folder is the much more natural concept than
182 a draft message. MH's mail storage consists of folders and messages,
183 the messages named with ascending numbers. A draft message breaks with this
184 concept by introducing a message in a file named
185 .Fn draft .
186 This draft
187 message is special. It can not be simply listed with the available tools,
188 but instead requires special switches. I.e. corner-cases were
189 introduced. A draft folder, in contrast, does not introduce such
190 corner-cases. The available tools can operate on the messages within that
191 folder like on any messages within any mail folders. The only difference
192 is the fact that the default folder for
193 .Pn send
194 is the draft folder,
195 instead of the current folder, like for all other tools.
196 .P
197 The trivial part of the change was activating the draft folder facility
198 by default and setting a default name for this folder. Obviously, I chose
199 the name
200 .Fn +drafts .
201 This made the
202 .Sw \-draftfolder
203 and
204 .Sw \-draftmessage
205 switches useless, and I could remove them.
206 The more difficult but also the part that showed the real improvement,
207 was updating the tools to the new concept.
208 .Sw \-draft
209 switches could
210 be dropped, as operating on a draft message became indistinguishable to
211 operating on any other message for the tools.
212 .Pn comp
213 still has its
214 .Sw \-use
215 switch for switching between its two modes: (1) Compose a new
216 draft, possibly by taking some existing message as a form. (2) Modify
217 an existing draft. In either case, the behavior of
218 .Pn comp is
219 deterministic. There is no more need to query the user. I consider this
220 a major improvement. By making
221 .Pn send
222 simply operate on the current
223 message in the draft folder by default, with message and folder both
224 overridable by specifying them on the command line, it is now possible
225 to send a draft anywhere within the storage by simply specifying its folder
226 and name.
227 .P
228 All theses changes converted special cases to regular cases, thus
229 simplifying the tools and increasing the flexibility.
231 .U2 "Trash Folder
232 .P
233 Similar to the situation for drafts is the situation for removed messages.
234 Historically, a message was deleted by renaming. A specific
235 \fIbackup prefix\fP, often comma (\c
236 .Fn , )
237 or hash (\c
238 .Fn # ),
239 being prepended to the file name. Thus, MH wouldn't recognize the file
240 as a message anymore, as only files whose name consists of digits only
241 are treated as messages. The removed messages remained as files in the
242 same directory and needed some maintenance job to truly delete them after
243 some grace time. Usually, by running a command similar to
244 .DS
245 find /home/user/Mail \-ctime +7 \-name ',*' | xargs rm
246 .DE
247 in a cron job. Within the grace time interval
248 the original message could be restored by stripping the
249 the backup prefix from the file name. If however, the last message of
250 a folder is been removed \(en say message
251 .Fn 6
252 becomes file
253 .Fn ,6
254 \(en and a new message enters the same folder, thus the same
255 numbered being given again \(en in our case
256 .Fn 6
257 \(en, if that one
258 is removed too, then the backup of the former message gets overwritten.
259 Thus, the ability to restore removed messages does not only depend on
260 the ``sweeping cron job'' but also on the removing of further messages.
261 This is undesireable, because the real mechanism is hidden from the user
262 and the concequences of further removals are not always obvious.
263 Further more, the backup files are scattered within the whole mail
264 storage, instead of being collected at one place.
265 .P
266 To improve the situation, the profile entry
267 .Pe rmmproc
268 (previously named
269 .Pe Delete-Prog )
270 was introduced, very early.
271 It could be set to any command, which would care for the mail removal
272 instead of taking the default action, described above.
273 Refiling the to-be-removed files to some wastebin folder was a common
274 example. Nmh's man page
275 .Mp rmm(1)
276 proposes
277 .Cl "refile +d
278 to move messages to the wastebin and
279 .Cl "rm `mhpath +d all`
280 the empty the wastebin.
281 Managing the message removal this way is a sane approach. It keeps
282 the removed messages in one place, makes it easy to remove the backup
283 files, and, most important, enables the user to use the tools of MH
284 itself to operate on the removed messages. One can
285 .Pn scan
286 them,
287 .Pn show
288 them, and restore them with
289 .Pn refile .
290 There's no more
291 need to use
292 .Pn mhpath
293 to switch over from MH tools to Unix tools \(en MH can do it all itself.
294 .P
295 This apporach matches perfect with the concepts of MH, thus making
296 it powerful. Hence, I made it the default. And even more, I also
297 removed the old backup prefix approach, as it is clearly less powerful.
298 Keeping unused alternative in the code is a bad choice as they likely
299 gather bugs, by not being constantly tested. Also, the increased code
300 size and more conditions crease the maintenance costs. By strictly
301 converting to the trash folder approach, I simplified the code base.
302 .Pn rmm
303 calls
304 .Pn refile
305 internally to move the to-be-removed
306 message to the trash folder (\c
307 .Fn +trash
308 by default). Messages
309 there can be operated on like on any other message in the storage.
310 The sweep clean, one can use
311 .Cl "rmm \-unlink +trash a" ,
312 where the
313 .Sw \-unlink
314 switch causes the files to be truly unliked instead
315 of moved to the trash folder.
318 .H1 "MH Directory Split
319 .P
320 In MH and nmh, a personal setup had consisted of two parts:
321 The MH profile, named
322 .Fn \&.mh_profile
323 and being located directly in the user's home directory.
324 And the MH directory, where all his mail messages and also his personal
325 forms, scan formats, other configuration files are stored. The location
326 of this directory could be user-chosen. The default was to name it
327 .Fn Mail
328 and have it directly in the home directory.
329 .P
330 I've never liked the data storage and the configuration to be intermixed.
331 They are different kinds of data. One part, are the messages,
332 which are the data to operate on. The other part, are the personal
333 configuration files, which are able to change the behavior of the operations.
334 The actual operations are defined in the profile, however.
335 .P
336 When storing data, one should try to group data by its type.
337 There's sense in the Unix file system hierarchy, where configuration
338 file are stored separate (\c
339 .Fn /etc )
340 to the programs (\c
341 .Fn /bin
342 and
343 .Fn /usr/bin )
344 to their sources (\c
345 .Fn /usr/src ).
346 Such separation eases the backup management, for instance.
347 .P
348 In mmh, I've reorganized the file locations.
349 Still there are two places:
350 There's the mail storage directory, which, like in MH, contains all the
351 messages, but, unlike in MH, nothing else.
352 Its location still is user-chosen, with the default name
353 .Fn Mail ,
354 in the user's home directory. This is much similar to the case in nmh.
355 The configuration files, however, are grouped together in the new directory
356 .Fn \&.mmh
357 in the user's home directory.
358 The user's profile now is a file, named
359 .Fn profile ,
360 in this mmh directory.
361 Consistently, the context file and all the personal forms, scan formats,
362 and the like, are also there.
363 .P
364 The naming changed with the relocation.
365 The directory where everything, except the profile, had been stored (\c
366 .Fn $HOME/Mail ),
367 used to be called \fIMH directory\fP. Now, this directory is called the
368 user's \fImail storage\fP. The name \fImmh directory\fP is now given to
369 the new directory
370 (\c
371 .Fn $HOME/.mmh ),
372 containing all the personal configuration files.
373 .P
374 The separation of the files by type of content is logical and convenient.
375 There are no functional differences as any possible setup known to me
376 can be implemented with both approaches, although likely a bit easier
377 with the new approach. The main goal of the change had been to provide
378 sensible storage locations for any type of personal mmh file.
379 .P
380 In order for one user to have multiple MH setups, he can use the
381 environment variable
382 .Ev MH
383 the point to a different profile file.
384 The MH directory (mail storage plus personal configuration files) is
385 defined by the
386 .Pe Path
387 profile entry.
388 The context file could be defined by the
389 .Pe context
390 profile entry or by the
391 .Ev MHCONTEXT
392 environment variable.
393 The latter is useful to have a distinct context (e.g. current folders)
394 in each terminal window, for instance.
395 In mmh, there are three environment variables now.
396 .Ev MMH
397 may be used to change the location of the mmh directory.
398 .Ev MMHP
399 and
400 .Ev MMHC
401 change the profile and context files, respectively.
402 Besides providing a more consistent feel (which simply is the result
403 of being designed anew), the set of personal configuration files can
404 be chosen independently from the profile (including mail storage location)
405 and context, now. Being it relevant for practical use or not, it
406 de-facto is an improvement. However, the main achievement is the
407 split between mail storage and personal configuration files.
410 .H1 "Path Notations
411 .P
412 foo
414 .H1 "Attachments
415 .P
416 foo
418 .H1 "mhshow to show Transition
419 .P
420 Since the very beginning, already in the first concept paper,
421 .Pn show
422 had been MH's mail display program.
423 .Pn show
424 found out which pathnames the relevant messages had and invoked
425 .Pn mhl
426 then to let it render the content.
427 With the advent of MIME, this approach wasn't sufficient anymore.
428 MIME messages can consist of multiple parts, some of which aren't
429 directly displayable, and text content can be encoded in
430 foreign charsets.
431 .Pn show 's
432 simple approach and
433 .Pn mhl 's
434 limited display facilities couldn't cope with the task any longer.
435 Instead of extending these tools, new ones were written from scratch
436 and then added to the MH toolchest. Doing so is encouraged by the
437 toolchest approach. The new tools could be added without interfearing
438 with the existing ones. This is great. It allowed MH to be the
439 first MUA to implement MIME.
440 .P
441 The new MIME features were added in form of the single program
442 .Pn mhn .
443 The command
444 .DS
445 mhn \-show 42
446 .DE
447 would show the MIME message numbered 42.
448 With the 1.0 release of nmh in February 1999, Richard Coleman finished
449 the split of
450 .Pn mhn
451 into a set of specialized programs, which together covered the
452 aspects of MIME. One of these resulting tools was
453 .Pn mhshow .
456 .H1 "Blind Carbon Copies
457 .P
458 foo
460 .H1 "Good Defaults
461 .P
462 foo
464 .H1 "Modularization
465 .P
466 foo
468 .H1 "Code style
469 .P
470 foo