docs/master
view ch03.roff @ 16:81f703140554
Wrote about the trash folder.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Sun, 22 Apr 2012 13:50:35 +0200 |
| parents | 55ec590cfa07 |
| children | b3c37947764e |
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 in 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 of dropping ancient functionality to remove old code,
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 sees it. Without the need to justify my decisions, I was able to quickly
40 remove code I considered ancient. The need to discuss my decisions with
41 peers likely would have slowed this process down. Of course, I did research
42 if a particular feature really should be dropped. Having not had any
43 contact to this feature within my computer life was a first indicator to
44 drop it, but I also asked others and searched the literature for modern
45 usage of the feature. If it appeared to be truly ancient, I dropped it.
46 The reason for dropping is always part of the commit message in the
47 version control system. Thus, it is easy for others to check their
48 view on the topic with mine and possibly to argue for reinclusion.
50 .U2 "MMDF maildrop support
51 .P
52 I did drop any support for the MMDF maildrop format. This type of format
53 is conceptionally similar to the mbox format, but uses four bytes with
54 value 1 (\fL^A^A^A^A\fP) as message delimiter,
55 instead of the string ``\fLFrom\0\fP''.
56 Due to the similarity and mbox being the de-facto standard maildrop
57 format on Unix, but also due to the larger influence of Sendmail than MMDF,
58 the MMDF maildrop format had vanished.
59 .P
60 The simplifications within the code were only moderate. Switches could
61 be removed from tools like
62 .L packf ,
63 which generate packed mailboxes. Only one packed mailbox format remained:
64 mbox.
65 The most important changes affect the equally named mail parsing routine in
66 .L sbr/m_getfld.c .
67 The direct MMDF code had been removed, but as now only one packed mailbox
68 format is left, code structure simplifications are likely possible.
69 The reason why they are still outstanding is the heavily optimized code
70 of \fLm_getfld()\fP. Changes beyond a small local scope \(en
71 which restructuring in its core is \(en cause a high risk of damaging
72 the intricate workings of the optimized code. This problem is know
73 to the developers of nmh, too. They also avoid touching this minefield
74 if possible.
76 .U2 "UUCP Bang Paths
77 .P
78 More questionably than the former topic is the removal of support for the
79 UUCP bang path address style. However, the user may translate the bang
80 paths on retrieval to Internet addresses and the other way on posting
81 messages. The former can be done my an MDA like procmail; the latter
82 by a sendmail wrapper. This would ensure that any address handling would
83 work as expected. However, it might just work well without any
84 such modifications, as mmh does not touch addresses much, in general.
85 But I can't ensure as I have never used an environment with bang paths.
86 Also, the behavior might break at any point in further development.
88 .U2 "Hardcopy terminal support
89 .P
90 More of a funny anecdote is the remaining of a check for printing to a
91 hardcopy terminal until Spring 2012, when I finally removed it.
92 I surely would be very happy to see such a terminal in action, maybe
93 actually being able to work on it, but I fear my chances are null.
94 .P
95 The check only prevented a pager to be placed between the outputting
96 program (\fLmhl\fP) and the terminal. This could have been ensured with
97 the \fL-nomoreproc\fP at the command line statically, too.
99 .U2 "Removed support for header fields
100 .P
101 The `Encrypted' header had been introduced by RFC\^822, but already
102 marked legacy in RFC 2822. It was superseded by FIXME.
103 Mmh does no more support this header.
104 .P
105 `Content-MD5' headers were introduced by RFC\^1864. They provide only
106 a verification of data corruption during the transfer. By no means can
107 they ensure verbatim end-to-end delivery of the contents. This is clearly
108 stated in the RFC. The proper approach to provide verificationability
109 of content in an end-to-end relationship is the use of digital cryptography
110 (RFCs FIXME). On the other hand, transfer protocols should ensure the
111 integrity of the transmission. In combinations these two approaches
112 make the `Content-MD5' header field useless. In consequence, I removed
113 the support for it. By this removal, MD5 computation is not needed
114 anywhere in mmh. Hence, over 500 lines of code were removed by this one
115 change. Even if the `Content-MD5' header field is useful sometimes,
116 I value its usefulnes less than the improvement in maintainability, caused
117 by the removal.
120 .H1 "Draft and Trash Folders
121 .U2 "Draft Folder
122 .P
123 Historically, MH provided exactly one draft message, named `\fLdraft\fP' and
124 being located in the MH directory. When starting to compose another message
125 before the former one was sent, the user had been questioned wether to use,
126 refile or replace the old draft. Working on multiple drafts at the same time
127 was impossible. One could only work on them in alteration by refiling the
128 previous one to some directory and fetching some other one for reediting.
129 This manual draft management needed to be done each time the user wanted
130 to switch between editing one draft to editing another.
131 .P
132 To allow true parallel editing of drafts, in a straight forward way, the
133 draft folder facility exists. It had been introduced already in July 1984
134 by Marshall T. Rose. The facility was deactivated by default.
135 Even in nmh, the draft folder facility remained deactivated by default.
136 At least, Richard Coleman added the man page \fImh-draft(5)\fI to document
137 the feature well.
138 .P
139 The only advantage of not using the draft folder facility is the static
140 name of the draft file. This could be an issue for MH frontends like mh-e.
141 But as they likely want to provide working on multiple drafts in parallel,
142 the issue is only concerning compatibility. The aim of nmh to stay compatible
143 prevented the default activation of the draft folder facility.
144 .P
145 On the other hand, a draft folder is the much more natural concept than
146 a draft message. MH's mail storage consists of folders and messages,
147 the messages named with ascending numbers. A draft message breaks with this
148 concept by introducing a message in a file named ``draft''. This draft
149 message is special. It can not be simply listed with the available tools,
150 but instead special switches were required. I.e. corner-cases were
151 introduced. A draft folder, in contrast, does not introduce such
152 corner-cases. The available tools can operate on the messages within that
153 folder like on any messages within any mail folders. The only difference
154 is the fact that the default folder for \fLsend\fP is the draft folder,
155 instead of the current folder, like for all other tools.
156 .P
157 The trivial part of the change was activating the draft folder facility
158 by default and setting a default name for this folder. Obviously, I chose
159 the name ``\fL+drafts\fP''. This made the \fL\-draftfolder\fP and
160 \fL\-draftmessage\fP switches useless, thus I could remove them two.
161 The more difficult but also the part that showed the real improvement,
162 was updating the tools to the new concept. \fL\-draft\fP switches could
163 be dropped, as operating on a draft message became indistinguishable to
164 operating on any other message for the tools. \fLcomp\fP still has its
165 \fL\-use\fP switch for switching between its two modes: (1) Compose a new
166 draft, possibly by taking some existing message as a form. (2) Modify
167 an existing draft. In either case, the behavior of \fLcomp\fP is
168 deterministic. There is no more need to query the user. I consider this
169 a major improvement. By making \fLsend\fP simply operate on the current
170 message in the draft folder by default, with both, message and folder,
171 overridable by specifying them on the command line, it is now possible
172 to send any message in the storage by simply specifying its folder and
173 name.
174 .P
175 All theses changes converted special cases to regular cases, thus
176 simplifying the tools and increasing the flexibility.
178 .U2 "Trash Folder
179 .P
180 Similar to the situation for drafts is the situation for removed messages.
181 Historically, a message was deleted by renaming. A specific
182 \fIbackup prefix\fP, often comma (\fL,\fP) or hash (\fL#\fP),
183 being prepended to the file name. Thus, MH wouldn't recognize the file
184 as a message anymore, as only files whose name consists of digits only
185 are treated as messages. The removed messages remained as files in the
186 same directory and needed some maintenance job to truly delete them after
187 some grace time. Usually, by running a command similar to
188 .DS
189 find /home/user/Mail \-ctime +7 \-name ',*' | xargs rm
190 .DE
191 in a cron job. Within the grace time interval
192 the original message could be restored by stripping the
193 the backup prefix from the file name. If however, the last message of
194 a folder is been removed \(en say message `\fL6\fP' becomes file
195 `\fL,6\fP' \(en and a new message enters the same folder, thus the same
196 numbered being given again \(en in out case `\fL6\fP' \(en, if that one
197 is removed too, then the backup of the former message gets over written.
198 Thus, the ability to restore removed messages does not only depend on
199 the ``sweeping cron job'' but also on the removing of further messages.
200 This is undesireable, because the real mechanism is hidden from the user
201 and the concequences of further removals are not always obvious.
202 Further more, the backup files are scattered within the whole mail
203 storage, instead of being collected at one place.
204 .P
205 To improve the situation, the profile entry \fIrmmproc\fP
206 (previously named \fIDelete-Prog\fP) was introduced, very early.
207 It could be set to any command, which would care for the mail removal
208 instead of taking the default action, described above.
209 Refiling the to-be-removed files to some wastebin folder was a common
210 example. Nmh's man page for \fLrmm(1)\fP proposes `\fLrefile +d\fP'
211 (implemented through a shell alias) and `\fLrm `mhpath +d all`\fP'
212 the empty the wastebin.
213 Managing the message removal this way is a sane approach. It keeps
214 the removed messages in one place, makes it easy to remove the backup
215 files, and, most important, enables the user to use the tools of MH
216 itself to operate on the removed messages. One can \fLscan\fP them,
217 \fLshow\fP them, and restore them with \fLrefile(1)\fP. There's no more
218 need to use \fLmhpath\fP to switch over from MH tools to Unix tools
219 \(en MH can do it all itself.
220 .P
221 This apporach is matches perfect with the concepts of MH, thus making
222 it powerful. Hence, I made it the default. And even more, I also
223 removed the old backup prefix approach, as it is clearly less powerful.
224 Keeping unused alternative in the code is a bad choice as they likely
225 gather bugs, by not being constantly tested. Also, the increased code
226 size and more conditions crease the maintenance costs. By strictly
227 converting to the trash folder approach, I simplified the code base.
228 \fLrmm(1)\fP calls \fLrefile(1)\fP internally to move the to-be-removed
229 message to the trash folder (`\fL+trash\fP' by default). Messages
230 there can be operated on like on any other message in the storage.
231 The sweep clean, one can use `\fLrmm \-unlink +trash a\fP', where
232 the `\fL\-unlink\fP' switch causes the files to be truly unliked instead
233 of moved to the trash folder.
236 .H1 "Paths to ...
237 .P
238 foo
240 .H1 "Path Notations
241 .P
242 foo
244 .H1 "Attachments
245 .P
246 foo
248 .H1 "Blind Carbon Copies
249 .P
250 foo
252 .H1 "Good Defaults
253 .P
254 foo
256 .H1 "Modularization
257 .P
258 foo
260 .H1 "Code style
261 .P
262 foo