| rev |
line source |
|
meillo@58
|
1 .H0 "Discussion
|
|
meillo@0
|
2 .P
|
|
meillo@58
|
3 This main chapter discusses the practical work done in the mmh project.
|
|
meillo@58
|
4 It is structured along the goals to achieve. The concrete work done
|
|
meillo@58
|
5 is described in the examples of how the general goals were achieved.
|
|
meillo@58
|
6
|
|
meillo@58
|
7
|
|
meillo@58
|
8
|
|
meillo@58
|
9
|
|
meillo@58
|
10 .H1 "Stream-lining
|
|
meillo@58
|
11
|
|
meillo@58
|
12
|
|
meillo@58
|
13 .H2 "Removal of non-MUA Tools
|
|
meillo@0
|
14 .P
|
|
meillo@58
|
15 MH had been considered an all-in-one system for mail handling.
|
|
meillo@58
|
16 The community around nmh has a similar understanding.
|
|
meillo@58
|
17 In fundamental difference, I believe that mmh should be a MUA but
|
|
meillo@58
|
18 nothing more. I believe that all-in-one mail systems are not the way
|
|
meillo@58
|
19 to go. There are excellent specialized MTAs, like Postfix;
|
|
meillo@58
|
20 there are specialized MDAs, like Procmail; there are specialized
|
|
meillo@58
|
21 MRAs, like Fetchmail. I believe it's best to use them instead of
|
|
meillo@58
|
22 providing the same function ourselves. Doing something well requires to
|
|
meillo@58
|
23 focus on this particular aspect or a small set of aspects. The more
|
|
meillo@58
|
24 it is possible to focus, the better the result in this particular
|
|
meillo@58
|
25 area will be. The limiting resource in Free Software community development
|
|
meillo@58
|
26 usually is human power. If the low development power is even parted
|
|
meillo@58
|
27 into multiple development areas, it will hardly be possible to
|
|
meillo@58
|
28 compete with the specialists in the various fields. This is even
|
|
meillo@58
|
29 increased, given the small community \(en developers and users \(en
|
|
meillo@58
|
30 that MH-based mail systems have. In consequence, I believe that the
|
|
meillo@58
|
31 available resources should be concentrated at the point where MH is
|
|
meillo@58
|
32 most unique. This is clearly the MUA part.
|
|
meillo@58
|
33 .P
|
|
meillo@58
|
34 Several of nmh's tools were removed from mmh because they didn't
|
|
meillo@58
|
35 match the main focus of adding to the MUA's task.
|
|
meillo@58
|
36 .P
|
|
meillo@58
|
37 .Pn conflict
|
|
meillo@58
|
38 was removed because it is a mail system maintenance tool.
|
|
meillo@58
|
39 Besides, it also checks the
|
|
meillo@58
|
40 .Fn /etc/passwd
|
|
meillo@58
|
41 and
|
|
meillo@58
|
42 .Fn /etc/group
|
|
meillo@58
|
43 files.
|
|
meillo@58
|
44 The tool might be useful, but it should not be shipped with mmh.
|
|
meillo@58
|
45 .P
|
|
meillo@58
|
46 .Pn rcvtty
|
|
meillo@58
|
47 was removed because its usecase of writing to the user's terminal
|
|
meillo@58
|
48 on receiving of mail is hardly wanted today. If users like to be
|
|
meillo@58
|
49 informed of new mail, then using the shell's
|
|
meillo@58
|
50 .Ev MAILPATH
|
|
meillo@58
|
51 variable or different (graphical) notifications are likely more
|
|
meillo@58
|
52 appealing. Writing directly to other terminals is hardly ever wanted
|
|
meillo@58
|
53 today. If though one wants to have it this way, the standard tool
|
|
meillo@58
|
54 .Pn write
|
|
meillo@58
|
55 can be used in a way similar to:
|
|
meillo@58
|
56 .DS
|
|
meillo@58
|
57 scan -file - | write `id -un`
|
|
meillo@58
|
58 .DE
|
|
meillo@58
|
59 .P
|
|
meillo@58
|
60 When the new attachment system was introduced,
|
|
meillo@58
|
61 .Pn viamail
|
|
meillo@58
|
62 was removed because then
|
|
meillo@58
|
63 .Pn forw
|
|
meillo@58
|
64 could cover the task itself.
|
|
meillo@58
|
65 The wrapper program
|
|
meillo@58
|
66 .Pn sendfiles
|
|
meillo@58
|
67 was rewritten as a shell script to use
|
|
meillo@58
|
68 .Pn forw .
|
|
meillo@58
|
69 .P
|
|
meillo@58
|
70 .Pn msgchk
|
|
meillo@58
|
71 was removed as it became hardly useful when POP support was removed.
|
|
meillo@58
|
72 It is questionable if
|
|
meillo@58
|
73 .Pn msgchk
|
|
meillo@58
|
74 provides more information than:
|
|
meillo@58
|
75 .DS
|
|
meillo@58
|
76 ls -l /var/mail/meillo
|
|
meillo@58
|
77 .DE
|
|
meillo@58
|
78 It does separate between old and new mail, but that's not very
|
|
meillo@58
|
79 useful and can be found out with
|
|
meillo@58
|
80 .Pn stat (1)
|
|
meillo@58
|
81 too. A very small shell script could care for the form of output.
|
|
meillo@58
|
82 As mmh's inc only incorporates mail from the user's local maildrop
|
|
meillo@58
|
83 and thus no long data transfers are involved,
|
|
meillo@58
|
84 there's no need to check for new mail before incorporating it.
|
|
meillo@58
|
85 .P
|
|
meillo@58
|
86 .Pn msh
|
|
meillo@58
|
87 was removed because the tool was in conflict with the original
|
|
meillo@58
|
88 philosophy of MH. It provided an interactive shell to access the
|
|
meillo@58
|
89 features of MH. One major feature of MH is being a tool chest.
|
|
meillo@58
|
90 .Pn msh
|
|
meillo@58
|
91 wouldn't be just another shell, tailored to the needs of mail
|
|
meillo@58
|
92 handling, but one large program to have the MH tools built in.
|
|
meillo@58
|
93 It's main use was for accessing Bulletin Boards, which have seized to
|
|
meillo@58
|
94 be popular. Removing
|
|
meillo@58
|
95 .Pn msh ,
|
|
meillo@58
|
96 together with the truly obsolete programs
|
|
meillo@58
|
97 .Pn vmh
|
|
meillo@58
|
98 and
|
|
meillo@58
|
99 .Pn wmh ,
|
|
meillo@58
|
100 saved more than 7\|000 lines of C code \(en a major achievement.
|
|
meillo@0
|
101
|
|
meillo@58
|
102 .U2 "Removal of the MTS
|
|
meillo@58
|
103 .P
|
|
meillo@58
|
104
|
|
meillo@58
|
105
|
|
meillo@58
|
106 .H2 "mhshow show Merge
|
|
meillo@58
|
107 .P
|
|
meillo@58
|
108 Since the very beginning, already in the first concept paper,
|
|
meillo@58
|
109 .Pn show
|
|
meillo@58
|
110 had been MH's mail display program.
|
|
meillo@58
|
111 .Pn show
|
|
meillo@58
|
112 found out which pathnames the relevant messages had and invoked
|
|
meillo@58
|
113 .Pn mhl
|
|
meillo@58
|
114 then to let it render the content.
|
|
meillo@58
|
115 With the advent of MIME, this approach wasn't sufficient anymore.
|
|
meillo@58
|
116 MIME messages can consist of multiple parts, some of which aren't
|
|
meillo@58
|
117 directly displayable, and text content can be encoded in
|
|
meillo@58
|
118 foreign charsets.
|
|
meillo@58
|
119 .Pn show 's
|
|
meillo@58
|
120 simple approach and
|
|
meillo@58
|
121 .Pn mhl 's
|
|
meillo@58
|
122 limited display facilities couldn't cope with the task any longer.
|
|
meillo@58
|
123 Instead of extending these tools, new ones were written from scratch
|
|
meillo@58
|
124 and then added to the MH tool chest. Doing so is encouraged by the
|
|
meillo@58
|
125 tool chest approach. The new tools could be added without interfering
|
|
meillo@58
|
126 with the existing ones. This is great. It allowed MH to be the
|
|
meillo@58
|
127 first MUA to implement MIME.
|
|
meillo@58
|
128 .P
|
|
meillo@58
|
129 The new MIME features were added in form of the single program
|
|
meillo@58
|
130 .Pn mhn .
|
|
meillo@58
|
131 The command
|
|
meillo@58
|
132 .DS
|
|
meillo@58
|
133 mhn \-show 42
|
|
meillo@58
|
134 .DE
|
|
meillo@58
|
135 would show the MIME message numbered 42.
|
|
meillo@58
|
136 With the 1.0 release of nmh in February 1999, Richard Coleman finished
|
|
meillo@58
|
137 the split of
|
|
meillo@58
|
138 .Pn mhn
|
|
meillo@58
|
139 into a set of specialized programs, which together covered the
|
|
meillo@58
|
140 aspects of MIME. One of these resulting tools was
|
|
meillo@58
|
141 .Pn mhshow .
|
|
meillo@58
|
142
|
|
meillo@58
|
143
|
|
meillo@58
|
144 .H2 "Removal of Configure Options
|
|
meillo@58
|
145 .P
|
|
meillo@58
|
146
|
|
meillo@58
|
147 .H2 "Removal of switches
|
|
meillo@58
|
148 .P
|
|
meillo@58
|
149
|
|
meillo@58
|
150
|
|
meillo@58
|
151
|
|
meillo@58
|
152
|
|
meillo@58
|
153 .H1 "Moderizing
|
|
meillo@58
|
154
|
|
meillo@58
|
155
|
|
meillo@58
|
156 .H2 "Removal of Code Relicts
|
|
meillo@0
|
157 .P
|
|
meillo@51
|
158 The code base of mmh originates from the late Seventies,
|
|
meillo@51
|
159 had been extensively
|
|
meillo@51
|
160 worked on in the mid Eighties, and had been partly reorganized and extended
|
|
meillo@51
|
161 in the Nineties. Relicts of all those times had gathered in the code base.
|
|
meillo@12
|
162 My goal was to remove any ancient code parts. One part of the task was
|
|
meillo@12
|
163 converting obsolete code constructs to standard constructs, the other part
|
|
meillo@12
|
164 was dropping obsolete functions.
|
|
meillo@12
|
165 .P
|
|
meillo@12
|
166 As I'm not even thirty years old and have no more than seven years of
|
|
meillo@51
|
167 Unix experience, I needed to learn about the history in retrospective.
|
|
meillo@51
|
168 Older people likely have used those ancient constructs themselves
|
|
meillo@51
|
169 and have suffered from their incompatibilities and have longed for
|
|
meillo@12
|
170 standardization. Unfortunately, I have only read that others had done so.
|
|
meillo@12
|
171 This put me in a much more difficult positions when working on the old
|
|
meillo@12
|
172 code. I needed to recherche what other would have known by heart from
|
|
meillo@12
|
173 experience. All my programming experience comes from a time past ANSI C
|
|
meillo@12
|
174 and past POSIX. Although I knew about the times before, I took the
|
|
meillo@51
|
175 current state implicitly for granted most of the time.
|
|
meillo@12
|
176 .P
|
|
meillo@12
|
177 Being aware of
|
|
meillo@12
|
178 these facts, I rather let people with more historic experience solve the
|
|
meillo@12
|
179 task of converting the ancient code constructs to standardized ones.
|
|
meillo@12
|
180 Luckily, Lyndon Nerenberg focused on this task at the nmh project.
|
|
meillo@12
|
181 He converted large parts of the code to POSIX constructs, removing
|
|
meillo@12
|
182 the conditionals compilation for now standardized features.
|
|
meillo@12
|
183 I'm thankful for this task being solved. I only pulled the changes into
|
|
meillo@12
|
184 mmh.
|
|
meillo@12
|
185 .P
|
|
meillo@20
|
186 The other task \(en dropping ancient functionality to remove old code \(en
|
|
meillo@12
|
187 I did myself, though. My position to strip mmh to the bare minimum of
|
|
meillo@12
|
188 frequently used features is much more revolutional than the nmh community
|
|
meillo@20
|
189 likes it. Without the need to justify my decisions, I was able to quickly
|
|
meillo@20
|
190 remove functionality I considered ancient.
|
|
meillo@20
|
191 The need to discuss my decisions with
|
|
meillo@20
|
192 peers likely would have slowed this process down. Of course, I researched
|
|
meillo@12
|
193 if a particular feature really should be dropped. Having not had any
|
|
meillo@12
|
194 contact to this feature within my computer life was a first indicator to
|
|
meillo@12
|
195 drop it, but I also asked others and searched the literature for modern
|
|
meillo@12
|
196 usage of the feature. If it appeared to be truly ancient, I dropped it.
|
|
meillo@12
|
197 The reason for dropping is always part of the commit message in the
|
|
meillo@12
|
198 version control system. Thus, it is easy for others to check their
|
|
meillo@12
|
199 view on the topic with mine and possibly to argue for reinclusion.
|
|
meillo@12
|
200
|
|
meillo@12
|
201 .U2 "MMDF maildrop support
|
|
meillo@12
|
202 .P
|
|
meillo@12
|
203 I did drop any support for the MMDF maildrop format. This type of format
|
|
meillo@12
|
204 is conceptionally similar to the mbox format, but uses four bytes with
|
|
meillo@12
|
205 value 1 (\fL^A^A^A^A\fP) as message delimiter,
|
|
meillo@18
|
206 instead of the string ``\fLFrom\ \fP''.
|
|
meillo@12
|
207 Due to the similarity and mbox being the de-facto standard maildrop
|
|
meillo@12
|
208 format on Unix, but also due to the larger influence of Sendmail than MMDF,
|
|
meillo@12
|
209 the MMDF maildrop format had vanished.
|
|
meillo@12
|
210 .P
|
|
meillo@12
|
211 The simplifications within the code were only moderate. Switches could
|
|
meillo@12
|
212 be removed from tools like
|
|
meillo@12
|
213 .L packf ,
|
|
meillo@12
|
214 which generate packed mailboxes. Only one packed mailbox format remained:
|
|
meillo@12
|
215 mbox.
|
|
meillo@12
|
216 The most important changes affect the equally named mail parsing routine in
|
|
meillo@12
|
217 .L sbr/m_getfld.c .
|
|
meillo@12
|
218 The direct MMDF code had been removed, but as now only one packed mailbox
|
|
meillo@12
|
219 format is left, code structure simplifications are likely possible.
|
|
meillo@12
|
220 The reason why they are still outstanding is the heavily optimized code
|
|
meillo@18
|
221 of
|
|
meillo@18
|
222 .Fu m_getfld() .
|
|
meillo@18
|
223 Changes beyond a small local scope \(en
|
|
meillo@12
|
224 which restructuring in its core is \(en cause a high risk of damaging
|
|
meillo@12
|
225 the intricate workings of the optimized code. This problem is know
|
|
meillo@12
|
226 to the developers of nmh, too. They also avoid touching this minefield
|
|
meillo@12
|
227 if possible.
|
|
meillo@12
|
228
|
|
meillo@12
|
229 .U2 "UUCP Bang Paths
|
|
meillo@12
|
230 .P
|
|
meillo@12
|
231 More questionably than the former topic is the removal of support for the
|
|
meillo@12
|
232 UUCP bang path address style. However, the user may translate the bang
|
|
meillo@12
|
233 paths on retrieval to Internet addresses and the other way on posting
|
|
meillo@12
|
234 messages. The former can be done my an MDA like procmail; the latter
|
|
meillo@12
|
235 by a sendmail wrapper. This would ensure that any address handling would
|
|
meillo@12
|
236 work as expected. However, it might just work well without any
|
|
meillo@12
|
237 such modifications, as mmh does not touch addresses much, in general.
|
|
meillo@12
|
238 But I can't ensure as I have never used an environment with bang paths.
|
|
meillo@12
|
239 Also, the behavior might break at any point in further development.
|
|
meillo@12
|
240
|
|
meillo@12
|
241 .U2 "Hardcopy terminal support
|
|
meillo@12
|
242 .P
|
|
meillo@12
|
243 More of a funny anecdote is the remaining of a check for printing to a
|
|
meillo@12
|
244 hardcopy terminal until Spring 2012, when I finally removed it.
|
|
meillo@12
|
245 I surely would be very happy to see such a terminal in action, maybe
|
|
meillo@12
|
246 actually being able to work on it, but I fear my chances are null.
|
|
meillo@12
|
247 .P
|
|
meillo@12
|
248 The check only prevented a pager to be placed between the outputting
|
|
meillo@18
|
249 program (\c
|
|
meillo@18
|
250 .Pn mhl )
|
|
meillo@18
|
251 and the terminal. This could have been ensured with
|
|
meillo@18
|
252 the
|
|
meillo@18
|
253 .Sw \-nomoreproc
|
|
meillo@18
|
254 at the command line statically, too.
|
|
meillo@12
|
255
|
|
meillo@12
|
256 .U2 "Removed support for header fields
|
|
meillo@12
|
257 .P
|
|
meillo@12
|
258 The `Encrypted' header had been introduced by RFC\^822, but already
|
|
meillo@12
|
259 marked legacy in RFC 2822. It was superseded by FIXME.
|
|
meillo@12
|
260 Mmh does no more support this header.
|
|
meillo@12
|
261 .P
|
|
meillo@21
|
262 Native support for `Face' headers
|
|
meillo@21
|
263 had been removed, as well.
|
|
meillo@21
|
264 The feature is similar to the `X-Face' header in its intent,
|
|
meillo@21
|
265 but takes a different approach to store the image.
|
|
meillo@21
|
266 Instead of encoding the image data directly into the header,
|
|
meillo@21
|
267 the the header contains the hostname and UDP port where the image
|
|
meillo@21
|
268 date could be retrieved.
|
|
meillo@21
|
269 Neither `X-Face' nor the here described `Face' system
|
|
meillo@21
|
270 \**
|
|
meillo@21
|
271 .FS
|
|
meillo@21
|
272 There is also a newer but different system, invented 2005,
|
|
meillo@21
|
273 using `Face' headers.
|
|
meillo@21
|
274 It is the successor of `X-Face' providing colored PNG images.
|
|
meillo@21
|
275 .FE
|
|
meillo@21
|
276 became well used in the large scale.
|
|
meillo@21
|
277 It's still possible to use a Face systems,
|
|
meillo@21
|
278 although mmh does not provide support for any of the different systems
|
|
meillo@21
|
279 anymore. It's fairly easy to write a small shell script to
|
|
meillo@21
|
280 extract the embedded or fetch the external Face data and display the image.
|
|
meillo@21
|
281 Own Face headers can be added into the draft template files.
|
|
meillo@21
|
282 .P
|
|
meillo@12
|
283 `Content-MD5' headers were introduced by RFC\^1864. They provide only
|
|
meillo@12
|
284 a verification of data corruption during the transfer. By no means can
|
|
meillo@12
|
285 they ensure verbatim end-to-end delivery of the contents. This is clearly
|
|
meillo@12
|
286 stated in the RFC. The proper approach to provide verificationability
|
|
meillo@12
|
287 of content in an end-to-end relationship is the use of digital cryptography
|
|
meillo@12
|
288 (RFCs FIXME). On the other hand, transfer protocols should ensure the
|
|
meillo@12
|
289 integrity of the transmission. In combinations these two approaches
|
|
meillo@12
|
290 make the `Content-MD5' header field useless. In consequence, I removed
|
|
meillo@12
|
291 the support for it. By this removal, MD5 computation is not needed
|
|
meillo@12
|
292 anywhere in mmh. Hence, over 500 lines of code were removed by this one
|
|
meillo@12
|
293 change. Even if the `Content-MD5' header field is useful sometimes,
|
|
meillo@12
|
294 I value its usefulnes less than the improvement in maintainability, caused
|
|
meillo@12
|
295 by the removal.
|
|
meillo@12
|
296
|
|
meillo@20
|
297 .U2 "Prompter's Control Keys
|
|
meillo@20
|
298 .P
|
|
meillo@20
|
299 The program
|
|
meillo@20
|
300 .Pn prompter
|
|
meillo@20
|
301 queries the user to fill in a message form. When used by
|
|
meillo@20
|
302 .Pn comp
|
|
meillo@20
|
303 as:
|
|
meillo@20
|
304 .DS
|
|
meillo@20
|
305 comp \-editor prompter
|
|
meillo@20
|
306 .DE
|
|
meillo@20
|
307 the resulting behavior is similar to
|
|
meillo@20
|
308 .Pn mailx .
|
|
meillo@51
|
309 Apparently,
|
|
meillo@20
|
310 .Pn prompter
|
|
meillo@20
|
311 hadn't been touched lately. Otherwise it's hardly explainable why it
|
|
meillo@20
|
312 still offered the switches
|
|
meillo@20
|
313 .Sn \-erase \fUchr\fP
|
|
meillo@20
|
314 and
|
|
meillo@20
|
315 .Sn \-kill \fUchr\fP
|
|
meillo@20
|
316 to name the characters for command line editing.
|
|
meillo@21
|
317 The times when this had been necessary are long time gone.
|
|
meillo@20
|
318 Today these things work out-of-the-box, and if not, are configured
|
|
meillo@20
|
319 with the standard tool
|
|
meillo@20
|
320 .Pn stty .
|
|
meillo@20
|
321
|
|
meillo@21
|
322 .U2 "Vfork and Retry Loops
|
|
meillo@21
|
323 .P
|
|
meillo@51
|
324 MH creates many processes, which is a consequence of the tool chest approach.
|
|
meillo@21
|
325 In earlier times
|
|
meillo@21
|
326 .Fu fork()
|
|
meillo@21
|
327 had been an expensive system call, as the process's whole image needed
|
|
meillo@21
|
328 to be duplicated. One common case is replacing the image with
|
|
meillo@21
|
329 .Fu exec()
|
|
meillo@21
|
330 right after having forked the child process.
|
|
meillo@21
|
331 To speed up this case, the
|
|
meillo@21
|
332 .Fu vfork()
|
|
meillo@21
|
333 system call was invented at Berkeley. It completely omits copying the
|
|
meillo@21
|
334 image. If the image gets replaced right afterwards then unnecessary
|
|
meillo@21
|
335 work is omited. On old systems this results in large speed ups.
|
|
meillo@21
|
336 MH uses
|
|
meillo@21
|
337 .Fu vfork()
|
|
meillo@21
|
338 whenever possible.
|
|
meillo@21
|
339 .P
|
|
meillo@21
|
340 Memory management units that support copy-on-write semantics make
|
|
meillo@21
|
341 .Fu fork()
|
|
meillo@21
|
342 almost as fast as
|
|
meillo@21
|
343 .Fu vfork()
|
|
meillo@21
|
344 in the cases when they can be exchanged.
|
|
meillo@21
|
345 With
|
|
meillo@21
|
346 .Fu vfork()
|
|
meillo@51
|
347 being more error-prone and hardly faster, it's preferable to simply
|
|
meillo@21
|
348 use
|
|
meillo@21
|
349 .Fu fork()
|
|
meillo@21
|
350 instead.
|
|
meillo@21
|
351 .P
|
|
meillo@21
|
352 Related to the costs of
|
|
meillo@21
|
353 .Fu fork()
|
|
meillo@21
|
354 is the probability of its success.
|
|
meillo@21
|
355 Today on modern systems, the system call will succeed almost always.
|
|
meillo@51
|
356 In the Eighties on heavy loaded systems, as they were common at
|
|
meillo@21
|
357 universities, this had been different. Thus, many of the
|
|
meillo@21
|
358 .Fu fork()
|
|
meillo@21
|
359 calls were wrapped into loops to retry to fork several times in
|
|
meillo@21
|
360 short intervals, in case of previous failure.
|
|
meillo@21
|
361 In mmh, the program aborts at once if the fork failed.
|
|
meillo@21
|
362 The user can reexecute the command then. This is expected to be a
|
|
meillo@21
|
363 very rare case on modern systems, especially personal ones, which are
|
|
meillo@21
|
364 common today.
|
|
meillo@21
|
365
|
|
meillo@12
|
366
|
|
meillo@58
|
367 .H2 "Attachments
|
|
meillo@22
|
368 .P
|
|
meillo@58
|
369 MIME
|
|
meillo@58
|
370
|
|
meillo@58
|
371
|
|
meillo@58
|
372 .H2 "Digital Cryptography
|
|
meillo@22
|
373 .P
|
|
meillo@58
|
374 Signing and encryption.
|
|
meillo@58
|
375
|
|
meillo@58
|
376
|
|
meillo@58
|
377 .H2 "Good Defaults
|
|
meillo@22
|
378 .P
|
|
meillo@58
|
379 foo
|
|
meillo@58
|
380
|
|
meillo@58
|
381
|
|
meillo@58
|
382
|
|
meillo@58
|
383
|
|
meillo@58
|
384 .H1 "Code style
|
|
meillo@22
|
385 .P
|
|
meillo@58
|
386 foo
|
|
meillo@58
|
387
|
|
meillo@58
|
388
|
|
meillo@58
|
389 .H2 "Standard Code
|
|
meillo@22
|
390 .P
|
|
meillo@58
|
391 POSIX
|
|
meillo@22
|
392
|
|
meillo@22
|
393
|
|
meillo@58
|
394 .H2 "Separation
|
|
meillo@14
|
395
|
|
meillo@58
|
396 .U2 "MH Directory Split
|
|
meillo@0
|
397 .P
|
|
meillo@19
|
398 In MH and nmh, a personal setup had consisted of two parts:
|
|
meillo@19
|
399 The MH profile, named
|
|
meillo@19
|
400 .Fn \&.mh_profile
|
|
meillo@19
|
401 and being located directly in the user's home directory.
|
|
meillo@19
|
402 And the MH directory, where all his mail messages and also his personal
|
|
meillo@19
|
403 forms, scan formats, other configuration files are stored. The location
|
|
meillo@19
|
404 of this directory could be user-chosen. The default was to name it
|
|
meillo@19
|
405 .Fn Mail
|
|
meillo@19
|
406 and have it directly in the home directory.
|
|
meillo@19
|
407 .P
|
|
meillo@19
|
408 I've never liked the data storage and the configuration to be intermixed.
|
|
meillo@19
|
409 They are different kinds of data. One part, are the messages,
|
|
meillo@19
|
410 which are the data to operate on. The other part, are the personal
|
|
meillo@19
|
411 configuration files, which are able to change the behavior of the operations.
|
|
meillo@19
|
412 The actual operations are defined in the profile, however.
|
|
meillo@19
|
413 .P
|
|
meillo@19
|
414 When storing data, one should try to group data by its type.
|
|
meillo@19
|
415 There's sense in the Unix file system hierarchy, where configuration
|
|
meillo@19
|
416 file are stored separate (\c
|
|
meillo@19
|
417 .Fn /etc )
|
|
meillo@19
|
418 to the programs (\c
|
|
meillo@19
|
419 .Fn /bin
|
|
meillo@19
|
420 and
|
|
meillo@19
|
421 .Fn /usr/bin )
|
|
meillo@19
|
422 to their sources (\c
|
|
meillo@19
|
423 .Fn /usr/src ).
|
|
meillo@19
|
424 Such separation eases the backup management, for instance.
|
|
meillo@19
|
425 .P
|
|
meillo@19
|
426 In mmh, I've reorganized the file locations.
|
|
meillo@19
|
427 Still there are two places:
|
|
meillo@19
|
428 There's the mail storage directory, which, like in MH, contains all the
|
|
meillo@19
|
429 messages, but, unlike in MH, nothing else.
|
|
meillo@19
|
430 Its location still is user-chosen, with the default name
|
|
meillo@19
|
431 .Fn Mail ,
|
|
meillo@19
|
432 in the user's home directory. This is much similar to the case in nmh.
|
|
meillo@19
|
433 The configuration files, however, are grouped together in the new directory
|
|
meillo@19
|
434 .Fn \&.mmh
|
|
meillo@19
|
435 in the user's home directory.
|
|
meillo@19
|
436 The user's profile now is a file, named
|
|
meillo@19
|
437 .Fn profile ,
|
|
meillo@19
|
438 in this mmh directory.
|
|
meillo@19
|
439 Consistently, the context file and all the personal forms, scan formats,
|
|
meillo@19
|
440 and the like, are also there.
|
|
meillo@19
|
441 .P
|
|
meillo@19
|
442 The naming changed with the relocation.
|
|
meillo@19
|
443 The directory where everything, except the profile, had been stored (\c
|
|
meillo@19
|
444 .Fn $HOME/Mail ),
|
|
meillo@19
|
445 used to be called \fIMH directory\fP. Now, this directory is called the
|
|
meillo@19
|
446 user's \fImail storage\fP. The name \fImmh directory\fP is now given to
|
|
meillo@19
|
447 the new directory
|
|
meillo@19
|
448 (\c
|
|
meillo@19
|
449 .Fn $HOME/.mmh ),
|
|
meillo@19
|
450 containing all the personal configuration files.
|
|
meillo@19
|
451 .P
|
|
meillo@19
|
452 The separation of the files by type of content is logical and convenient.
|
|
meillo@19
|
453 There are no functional differences as any possible setup known to me
|
|
meillo@19
|
454 can be implemented with both approaches, although likely a bit easier
|
|
meillo@19
|
455 with the new approach. The main goal of the change had been to provide
|
|
meillo@19
|
456 sensible storage locations for any type of personal mmh file.
|
|
meillo@19
|
457 .P
|
|
meillo@19
|
458 In order for one user to have multiple MH setups, he can use the
|
|
meillo@19
|
459 environment variable
|
|
meillo@19
|
460 .Ev MH
|
|
meillo@19
|
461 the point to a different profile file.
|
|
meillo@19
|
462 The MH directory (mail storage plus personal configuration files) is
|
|
meillo@19
|
463 defined by the
|
|
meillo@19
|
464 .Pe Path
|
|
meillo@19
|
465 profile entry.
|
|
meillo@19
|
466 The context file could be defined by the
|
|
meillo@19
|
467 .Pe context
|
|
meillo@19
|
468 profile entry or by the
|
|
meillo@19
|
469 .Ev MHCONTEXT
|
|
meillo@19
|
470 environment variable.
|
|
meillo@19
|
471 The latter is useful to have a distinct context (e.g. current folders)
|
|
meillo@19
|
472 in each terminal window, for instance.
|
|
meillo@19
|
473 In mmh, there are three environment variables now.
|
|
meillo@19
|
474 .Ev MMH
|
|
meillo@19
|
475 may be used to change the location of the mmh directory.
|
|
meillo@19
|
476 .Ev MMHP
|
|
meillo@19
|
477 and
|
|
meillo@19
|
478 .Ev MMHC
|
|
meillo@19
|
479 change the profile and context files, respectively.
|
|
meillo@19
|
480 Besides providing a more consistent feel (which simply is the result
|
|
meillo@19
|
481 of being designed anew), the set of personal configuration files can
|
|
meillo@19
|
482 be chosen independently from the profile (including mail storage location)
|
|
meillo@19
|
483 and context, now. Being it relevant for practical use or not, it
|
|
meillo@19
|
484 de-facto is an improvement. However, the main achievement is the
|
|
meillo@19
|
485 split between mail storage and personal configuration files.
|
|
meillo@17
|
486
|
|
meillo@0
|
487
|
|
meillo@58
|
488 .H2 "Modularization
|
|
meillo@0
|
489 .P
|
|
meillo@58
|
490 whatnowproc
|
|
meillo@0
|
491 .P
|
|
meillo@49
|
492 The \fIMH library\fP
|
|
meillo@49
|
493 .Fn libmh.a
|
|
meillo@49
|
494 collects a bunch of standard functions that many of the MH tools need,
|
|
meillo@49
|
495 like reading the profile or context files.
|
|
meillo@49
|
496 This doesn't hurt the separation.
|
|
meillo@49
|
497
|
|
meillo@58
|
498
|
|
meillo@58
|
499 .H2 "Style
|
|
meillo@58
|
500 .P
|
|
meillo@58
|
501 Code layout, goto, ...
|
|
meillo@58
|
502
|
|
meillo@58
|
503
|
|
meillo@58
|
504
|
|
meillo@58
|
505
|
|
meillo@58
|
506 .H1 "Concept Exploitation/Homogeniety
|
|
meillo@58
|
507
|
|
meillo@58
|
508
|
|
meillo@58
|
509 .H2 "Draft Folder
|
|
meillo@58
|
510 .P
|
|
meillo@58
|
511 Historically, MH provided exactly one draft message, named
|
|
meillo@58
|
512 .Fn draft
|
|
meillo@58
|
513 and
|
|
meillo@58
|
514 being located in the MH directory. When starting to compose another message
|
|
meillo@58
|
515 before the former one was sent, the user had been questioned whether to use,
|
|
meillo@58
|
516 refile or replace the old draft. Working on multiple drafts at the same time
|
|
meillo@58
|
517 was impossible. One could only work on them in alteration by refiling the
|
|
meillo@58
|
518 previous one to some directory and fetching some other one for reediting.
|
|
meillo@58
|
519 This manual draft management needed to be done each time the user wanted
|
|
meillo@58
|
520 to switch between editing one draft to editing another.
|
|
meillo@58
|
521 .P
|
|
meillo@58
|
522 To allow true parallel editing of drafts, in a straight forward way, the
|
|
meillo@58
|
523 draft folder facility exists. It had been introduced already in July 1984
|
|
meillo@58
|
524 by Marshall T. Rose. The facility was deactivated by default.
|
|
meillo@58
|
525 Even in nmh, the draft folder facility remained deactivated by default.
|
|
meillo@58
|
526 At least, Richard Coleman added the man page
|
|
meillo@58
|
527 .Mp mh-draft(5)
|
|
meillo@58
|
528 to document
|
|
meillo@58
|
529 the feature well.
|
|
meillo@58
|
530 .P
|
|
meillo@58
|
531 The only advantage of not using the draft folder facility is the static
|
|
meillo@58
|
532 name of the draft file. This could be an issue for MH frontends like mh-e.
|
|
meillo@58
|
533 But as they likely want to provide working on multiple drafts in parallel,
|
|
meillo@58
|
534 the issue is only concerning compatibility. The aim of nmh to stay compatible
|
|
meillo@58
|
535 prevented the default activation of the draft folder facility.
|
|
meillo@58
|
536 .P
|
|
meillo@58
|
537 On the other hand, a draft folder is the much more natural concept than
|
|
meillo@58
|
538 a draft message. MH's mail storage consists of folders and messages,
|
|
meillo@58
|
539 the messages named with ascending numbers. A draft message breaks with this
|
|
meillo@58
|
540 concept by introducing a message in a file named
|
|
meillo@58
|
541 .Fn draft .
|
|
meillo@58
|
542 This draft
|
|
meillo@58
|
543 message is special. It can not be simply listed with the available tools,
|
|
meillo@58
|
544 but instead requires special switches. I.e. corner-cases were
|
|
meillo@58
|
545 introduced. A draft folder, in contrast, does not introduce such
|
|
meillo@58
|
546 corner-cases. The available tools can operate on the messages within that
|
|
meillo@58
|
547 folder like on any messages within any mail folders. The only difference
|
|
meillo@58
|
548 is the fact that the default folder for
|
|
meillo@58
|
549 .Pn send
|
|
meillo@58
|
550 is the draft folder,
|
|
meillo@58
|
551 instead of the current folder, like for all other tools.
|
|
meillo@58
|
552 .P
|
|
meillo@58
|
553 The trivial part of the change was activating the draft folder facility
|
|
meillo@58
|
554 by default and setting a default name for this folder. Obviously, I chose
|
|
meillo@58
|
555 the name
|
|
meillo@58
|
556 .Fn +drafts .
|
|
meillo@58
|
557 This made the
|
|
meillo@58
|
558 .Sw \-draftfolder
|
|
meillo@58
|
559 and
|
|
meillo@58
|
560 .Sw \-draftmessage
|
|
meillo@58
|
561 switches useless, and I could remove them.
|
|
meillo@58
|
562 The more difficult but also the part that showed the real improvement,
|
|
meillo@58
|
563 was updating the tools to the new concept.
|
|
meillo@58
|
564 .Sw \-draft
|
|
meillo@58
|
565 switches could
|
|
meillo@58
|
566 be dropped, as operating on a draft message became indistinguishable to
|
|
meillo@58
|
567 operating on any other message for the tools.
|
|
meillo@58
|
568 .Pn comp
|
|
meillo@58
|
569 still has its
|
|
meillo@58
|
570 .Sw \-use
|
|
meillo@58
|
571 switch for switching between its two modes: (1) Compose a new
|
|
meillo@58
|
572 draft, possibly by taking some existing message as a form. (2) Modify
|
|
meillo@58
|
573 an existing draft. In either case, the behavior of
|
|
meillo@58
|
574 .Pn comp is
|
|
meillo@58
|
575 deterministic. There is no more need to query the user. I consider this
|
|
meillo@58
|
576 a major improvement. By making
|
|
meillo@58
|
577 .Pn send
|
|
meillo@58
|
578 simply operate on the current
|
|
meillo@58
|
579 message in the draft folder by default, with message and folder both
|
|
meillo@58
|
580 overridable by specifying them on the command line, it is now possible
|
|
meillo@58
|
581 to send a draft anywhere within the storage by simply specifying its folder
|
|
meillo@58
|
582 and name.
|
|
meillo@58
|
583 .P
|
|
meillo@58
|
584 All theses changes converted special cases to regular cases, thus
|
|
meillo@58
|
585 simplifying the tools and increasing the flexibility.
|
|
meillo@58
|
586
|
|
meillo@58
|
587
|
|
meillo@58
|
588 .H2 "Trash Folder
|
|
meillo@58
|
589 .P
|
|
meillo@58
|
590 Similar to the situation for drafts is the situation for removed messages.
|
|
meillo@58
|
591 Historically, a message was deleted by renaming. A specific
|
|
meillo@58
|
592 \fIbackup prefix\fP, often comma (\c
|
|
meillo@58
|
593 .Fn , )
|
|
meillo@58
|
594 or hash (\c
|
|
meillo@58
|
595 .Fn # ),
|
|
meillo@58
|
596 being prepended to the file name. Thus, MH wouldn't recognize the file
|
|
meillo@58
|
597 as a message anymore, as only files whose name consists of digits only
|
|
meillo@58
|
598 are treated as messages. The removed messages remained as files in the
|
|
meillo@58
|
599 same directory and needed some maintenance job to truly delete them after
|
|
meillo@58
|
600 some grace time. Usually, by running a command similar to
|
|
meillo@58
|
601 .DS
|
|
meillo@58
|
602 find /home/user/Mail \-ctime +7 \-name ',*' | xargs rm
|
|
meillo@58
|
603 .DE
|
|
meillo@58
|
604 in a cron job. Within the grace time interval
|
|
meillo@58
|
605 the original message could be restored by stripping the
|
|
meillo@58
|
606 the backup prefix from the file name. If however, the last message of
|
|
meillo@58
|
607 a folder is been removed \(en say message
|
|
meillo@58
|
608 .Fn 6
|
|
meillo@58
|
609 becomes file
|
|
meillo@58
|
610 .Fn ,6
|
|
meillo@58
|
611 \(en and a new message enters the same folder, thus the same
|
|
meillo@58
|
612 numbered being given again \(en in our case
|
|
meillo@58
|
613 .Fn 6
|
|
meillo@58
|
614 \(en, if that one
|
|
meillo@58
|
615 is removed too, then the backup of the former message gets overwritten.
|
|
meillo@58
|
616 Thus, the ability to restore removed messages does not only depend on
|
|
meillo@58
|
617 the ``sweeping cron job'' but also on the removing of further messages.
|
|
meillo@58
|
618 This is undesirable, because the real mechanism is hidden from the user
|
|
meillo@58
|
619 and the consequences of further removals are not always obvious.
|
|
meillo@58
|
620 Further more, the backup files are scattered within the whole mail
|
|
meillo@58
|
621 storage, instead of being collected at one place.
|
|
meillo@58
|
622 .P
|
|
meillo@58
|
623 To improve the situation, the profile entry
|
|
meillo@58
|
624 .Pe rmmproc
|
|
meillo@58
|
625 (previously named
|
|
meillo@58
|
626 .Pe Delete-Prog )
|
|
meillo@58
|
627 was introduced, very early.
|
|
meillo@58
|
628 It could be set to any command, which would care for the mail removal
|
|
meillo@58
|
629 instead of taking the default action, described above.
|
|
meillo@58
|
630 Refiling the to-be-removed files to some garbage folder was a common
|
|
meillo@58
|
631 example. Nmh's man page
|
|
meillo@58
|
632 .Mp rmm(1)
|
|
meillo@58
|
633 proposes
|
|
meillo@58
|
634 .Cl "refile +d
|
|
meillo@58
|
635 to move messages to the garbage folder and
|
|
meillo@58
|
636 .Cl "rm `mhpath +d all`
|
|
meillo@58
|
637 the empty the garbage folder.
|
|
meillo@58
|
638 Managing the message removal this way is a sane approach. It keeps
|
|
meillo@58
|
639 the removed messages in one place, makes it easy to remove the backup
|
|
meillo@58
|
640 files, and, most important, enables the user to use the tools of MH
|
|
meillo@58
|
641 itself to operate on the removed messages. One can
|
|
meillo@58
|
642 .Pn scan
|
|
meillo@58
|
643 them,
|
|
meillo@58
|
644 .Pn show
|
|
meillo@58
|
645 them, and restore them with
|
|
meillo@58
|
646 .Pn refile .
|
|
meillo@58
|
647 There's no more
|
|
meillo@58
|
648 need to use
|
|
meillo@58
|
649 .Pn mhpath
|
|
meillo@58
|
650 to switch over from MH tools to Unix tools \(en MH can do it all itself.
|
|
meillo@58
|
651 .P
|
|
meillo@58
|
652 This approach matches perfect with the concepts of MH, thus making
|
|
meillo@58
|
653 it powerful. Hence, I made it the default. And even more, I also
|
|
meillo@58
|
654 removed the old backup prefix approach, as it is clearly less powerful.
|
|
meillo@58
|
655 Keeping unused alternative in the code is a bad choice as they likely
|
|
meillo@58
|
656 gather bugs, by not being constantly tested. Also, the increased code
|
|
meillo@58
|
657 size and more conditions crease the maintenance costs. By strictly
|
|
meillo@58
|
658 converting to the trash folder approach, I simplified the code base.
|
|
meillo@58
|
659 .Pn rmm
|
|
meillo@58
|
660 calls
|
|
meillo@58
|
661 .Pn refile
|
|
meillo@58
|
662 internally to move the to-be-removed
|
|
meillo@58
|
663 message to the trash folder (\c
|
|
meillo@58
|
664 .Fn +trash
|
|
meillo@58
|
665 by default). Messages
|
|
meillo@58
|
666 there can be operated on like on any other message in the storage.
|
|
meillo@58
|
667 The sweep clean, one can use
|
|
meillo@58
|
668 .Cl "rmm \-unlink +trash a" ,
|
|
meillo@58
|
669 where the
|
|
meillo@58
|
670 .Sw \-unlink
|
|
meillo@58
|
671 switch causes the files to be truly unliked instead
|
|
meillo@58
|
672 of moved to the trash folder.
|
|
meillo@58
|
673
|
|
meillo@58
|
674
|
|
meillo@58
|
675 .H2 "Path Notations
|
|
meillo@58
|
676 .P
|
|
meillo@58
|
677 foo
|
|
meillo@58
|
678
|
|
meillo@58
|
679
|
|
meillo@58
|
680 .H2 "MIME Integration
|
|
meillo@58
|
681 .P
|
|
meillo@58
|
682 user-visible access to whole messages and MIME parts are inherently
|
|
meillo@58
|
683 different
|
|
meillo@58
|
684
|
|
meillo@58
|
685
|
|
meillo@58
|
686 .H2 "Of One Cast
|
|
meillo@58
|
687 .P
|
