docs/master

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