Mercurial > docs > master

comparison ch03.roff @ 104:2818ca27d24c

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Various text rework.
author markus schnalke <meillo@marmaro.de>
date Thu, 21 Jun 2012 00:01:13 +0200
parents a782488c85f5
children 9ff356d84c57
comparison
equal deleted inserted replaced
103:da72a0720247 104:2818ca27d24c
1 .H0 "Discussion 1 .H0 "Discussion
2 .P 2 .P
3 This main chapter discusses the practical work done in the mmh project. 3 This main chapter discusses the practical work done in the mmh project.
4 It is structured along the goals to achieve. The concrete work done 4 It is structured along the goals to achieve.
5 The concrete work done
5 is described in the examples of how the general goals were achieved. 6 is described in the examples of how the general goals were achieved.
6 The discussion compares the current version of mmh with the state of 7 The discussion compares the current version of mmh with the state of
7 nmh just before the mmh project started, i.e. Fall 2011. 8 nmh just before the mmh project started, i.e. Fall 2011.
8 Current changes of nmh will be mentioned only as side notes. 9 Current changes of nmh will be mentioned only as side notes.
9 .\" XXX where do I discuss the parallel development of nmh? 10 .\" XXX where do I discuss the parallel development of nmh?
1637 1638
1638 1639
1639 .H2 "Code Relicts 1640 .H2 "Code Relicts
1640 .P 1641 .P
1641 My position to drop obsolete functionality of mmh to remove old code 1642 My position to drop obsolete functionality of mmh to remove old code
1642 is much more revolutional than the nmh community likes it. 1643 is much more revolutional than the nmh community likes to have it.
1643 Without the need to justify my decisions, I was able to quickly 1644 Working on an experimental version, I was able to quickly drop
1644 remove functionality I considered ancient. 1645 functionality I considered ancient.
1645 The need to discuss my decisions with 1646 The need for consensus with peers would have slowed this process down.
1646 peers likely would have slowed this process down. 1647 Without the need to justify my decisions, I was able to rush forward.
1647 Of course, I researched if a particular feature really should be dropped. 1648 In Dezember 2011, Paul Vixie motivated the nmh developers to just
1648 Having not had any 1649 do the work:
1649 contact to this feature within my computer life was a first indicator to 1650 .[
1650 drop it, but I also asked others and searched the literature for modern 1651 paul vixie edginess nmh-workers
1651 usage of the feature. 1652 .]
1652 If it appeared to be truly ancient, I dropped it. 1653 .QS
1653 The reason for dropping is always part of the commit message in the 1654 let's stop walking on egg shells with this code base. there's no need to
1655 discuss whether to keep using vfork, just note in [sic!] passing, [...]
1656 we don't need a separate branch for removing vmh
1657 or ridding ourselves of #ifdef's or removing posix replacement functions
1658 or depending on pure ansi/posix "libc".
1659 .QP
1660 these things should each be a day or two of work and the "main branch"
1661 should just be modern. [...]
1662 let's push forward, aggressively.
1663 .QE
1664 .LP
1665 I did so already in the months before.
1666 I pushed forward.
1667 I simply dropped the cruft.
1668 .P
1669 The decision to drop a feature was based on literature research and
1670 careful thinking, but whether having had contact to this particular
1671 feature within my own computer life served as a rule of thumb.
1672 My reasons are always made clean in the commit message for the
1654 version control system. 1673 version control system.
1655 Thus, it is easy for others to check their 1674 Hence, others can comprehend my view and argue for undoing the change
1656 view on the topic with mine and possibly to argue for reinclusion. 1675 if I have missed an important aspect.
1657 1676
1658 1677
1659 .U3 "MMDF maildrop support 1678 .U3 "Forking
1660 .P 1679 .P
1661 I did drop any support for the MMDF maildrop format. 1680 In being a tool chest, MH creates many processes.
1662 This type of format 1681 In earlier times
1663 is conceptionally similar to the mbox format, but uses four bytes with 1682 .Fu fork()
1664 value 1 (\fL^A^A^A^A\fP) as message delimiter, 1683 had been an expensive system call, because the process's image needed
1665 instead of the string ``\fLFrom\ \fP''. 1684 to be duplicated completely at once.
1666 Due to the similarity and mbox being the de-facto standard maildrop 1685 This was especially painfull in the common case when the image gets
1667 format on Unix, but also due to the larger influence of Sendmail than MMDF, 1686 replaced by a call to
1668 the MMDF maildrop format had vanished. 1687 .Fu exec()
1669 .P 1688 right after having forked the child process.
1670 The simplifications within the code were only moderate. 1689 The
1671 Switches could be removed from tools like 1690 .Fu vfork()
1672 .L packf , 1691 system call was invented to speed up this particular case.
1673 which generate packed mailboxes. 1692 It completely omits the duplication of the image.
1674 Only one packed mailbox format remained: mbox. 1693 On old systems this resulted in significant speed ups.
1675 The most important changes affect the equally named mail parsing routine in 1694 Therefore MH used
1676 .L sbr/m_getfld.c . 1695 .Fu vfork()
1677 The direct MMDF code had been removed, but as now only one packed mailbox 1696 whenever possible.
1678 format is left, code structure simplifications are likely possible. 1697 .P
1679 The reason why they are still outstanding is the heavily optimized code 1698 Modern memory management units support copy-on-write semantics, which make
1680 of 1699 .Fu fork()
1681 .Fu m_getfld() . 1700 almost as fast as
1682 Changes beyond a small local scope \(en 1701 .Fu vfork() .
1683 which restructuring in its core is \(en cause a high risk of damaging 1702 The man page of
1684 the intricate workings of the optimized code. 1703 .Mp vfork (2)
1685 This problem is know to the developers of nmh, too. 1704 in FreeBSD 8.0 states:
1686 They also avoid touching this minefield if possible. 1705 .QS
1687 1706 This system call will be eliminated when proper system sharing mechanisms
1688 .U3 "UUCP Bang Paths 1707 are implemented. Users should not depend on the memory sharing semantics
1689 .P 1708 of vfork() as it will, in that case, be made synonymous to fork(2).
1690 More questionably than the former topic is the removal of support for the 1709 .QE
1691 UUCP bang path address style. 1710 .LP
1692 However, the user may translate the bang 1711 Vixie supports the removal with the note that ``the last
1693 paths on retrieval to Internet addresses and the other way on posting 1712 system on which fork was so slow that an mh user would notice it, was
1694 messages. 1713 Eunice. that was 1987''.
1695 The former can be done my an MDA like procmail; the latter 1714 .[
1696 by a sendmail wrapper. 1715 nmh-workers vixie edginess
1697 This would ensure that any address handling would work as expected. 1716 .]
1698 However, it might just work well without any 1717 I replaced all calls to
1699 such modifications, as mmh does not touch addresses much, in general. 1718 .Fu vfork()
1700 But I can't ensure as I have never used an environment with bang paths. 1719 with calls to
1701 Also, the behavior might break at any point in further development. 1720 .Fu fork() .
1702 1721 .P
1703 .U3 "Hardcopy terminal support 1722 Related to the costs of
1704 .P 1723 .Fu fork()
1705 More of a funny anecdote is the remaining of a check for printing to a 1724 is the probability of its success.
1706 hardcopy terminal until Spring 2012, when I finally removed it. 1725 In the Eighties on heavy loaded systems, calls to
1707 I surely would be very happy to see such a terminal in action, maybe 1726 .Fu fork()
1708 actually being able to work on it, but I fear my chances are null. 1727 were prone to failure.
1709 .P 1728 Hence, many of the
1710 The check only prevented a pager to be placed between the outputting 1729 .Fu fork()
1711 program (\c 1730 calls in the code were wrapped into loops to retry the
1712 .Pn mhl ) 1731 .Fu fork()
1713 and the terminal. 1732 several times, for higher changes to succeed, eventually.
1714 This could have been ensured with the 1733 On modern systems, failing calls to
1715 .Sw -nomoreproc 1734 .Fu fork()
1716 at the command line statically, too. 1735 are unusual.
1717 1736 Hence, in the rare case when
1718 .U3 "Removed support for header fields 1737 .Fu fork()
1719 .P 1738 fails, mmh programs simply abort.
1739
1740
1741 .U3 "Obsolete Header Fields
1742 .BU
1720 The 1743 The
1721 .Hd Encrypted 1744 .Hd Encrypted
1722 header field had been introduced by RFC\^822, but already 1745 header field was introduced by RFC\|822,
1723 marked legacy in RFC 2822. 1746 but already marked legacy in RFC\|2822.
1724 It was superseded by FIXME. 1747 OpenPGP provides the basis for standardized exchange of encrypted
1725 Mmh does no more support this header field. 1748 messages [RFC\|4880, RFC\|3156].
1726 .P 1749 The support for
1750 .Hd Encrypted
1751 header fields is removed in mmh.
1752 .BU
1727 Native support for 1753 Native support for
1728 .Hd Face 1754 .Hd Face
1729 header fields had been removed, as well. 1755 header fields has been removed, as well.
1730 The feature is similar to the 1756 This feature is similar to the
1731 .Hd X-Face 1757 .Hd X-Face
1732 header field in its intent, 1758 header field in its intent,
1733 but takes a different approach to store the image. 1759 but takes a different approach to store the image.
1734 Instead of encoding the image data directly into the header field, 1760 Instead of encoding the image data directly into the header field,
1735 the it contains the hostname and UDP port where the image 1761 the it contains the hostname and UDP port where the image
1736 date could be retrieved. 1762 date could be retrieved.
1737 Neither 1763 There is even a third system, invented in 2005.
1764 Although it re-uses the
1765 .Hd Face
1766 header field, it is the successor of
1738 .Hd X-Face 1767 .Hd X-Face
1739 nor the here described 1768 with support for colored PNG images.
1740 .Hd Face 1769 None of the Face systems described here is popular today.
1741 system 1770 Hence, mmh has no direct support for them.
1742 \** 1771 .BU
1743 .FS 1772 The
1744 There is also a newer but different system, invented 2005,
1745 using
1746 .Hd Face
1747 headers.
1748 It is the successor of
1749 .Hd X-Face
1750 providing colored PNG images.
1751 .FE
1752 became well used in the large scale.
1753 It's still possible to use a Face systems,
1754 although mmh does not provide support for any of the different systems
1755 anymore. It's fairly easy to write a small shell script to
1756 extract the embedded or fetch the external Face data and display the image.
1757 Own
1758 .Hd Face
1759 header field can be added into the draft template files.
1760 .P
1761 .Hd Content-MD5 1773 .Hd Content-MD5
1762 header fields were introduced by RFC\^1864. They provide only 1774 header field was introduced by RFC\|1864.
1763 a verification of data corruption during the transfer. By no means can 1775 It provides detection of data corruption during the transfer.
1764 they ensure verbatim end-to-end delivery of the contents. This is clearly 1776 But it can not ensure verbatim end-to-end delivery of the contents
1765 stated in the RFC. The proper approach to provide verificationability 1777 [RFC\|1864].
1766 of content in an end-to-end relationship is the use of digital cryptography 1778 The proper approach to verify content integrity in an
1767 (RFCs FIXME). On the other hand, transfer protocols should ensure the 1779 end-to-end relationship is the use of digital cryptography.
1768 integrity of the transmission. In combinations these two approaches 1780 .\" XXX (RFCs FIXME).
1769 make the 1781 On the other hand, transfer protocols should detect corruption during
1782 each transmission. The TCP includes a checksum field therefore.
1783 These two approaches in combinations render the
1770 .Hd Content-MD5 1784 .Hd Content-MD5
1771 header field useless. In consequence, I removed 1785 header field superfluous.
1772 the support for it. By this removal, MD5 computation is not needed 1786 The nmh-workers mailing list archive contains about 4\|200 messages,
1773 anywhere in mmh. Hence, over 500 lines of code were removed by this one 1787 ranging from 1992 until today.
1774 change. Even if the 1788 Not a single one had a
1775 .Hd Content-MD5 1789 .Hd Content-MD5
1776 header field is useful sometimes, 1790 header field.
1777 I value its usefulness less than the improvement in maintainability, caused 1791 Neither did any of the 60\|000 messages in my personal mail storage.
1778 by the removal. 1792 Removing the support for this header field,
1793 removed the last place where MD5 computation was needed.
1794 Hence, the MD5 code could be removed as well.
1795 Over 500 lines of code vanished by this one change.
1796
1797
1798 .U3 "MMDF maildrop support
1799 .P
1800 This type of format is conceptionally similar to the mbox format,
1801 but uses a different message delimiter (`\fL^A^A^A^A\fP' instead of
1802 `\fLFrom\0\fP').
1803 Mbox is the de-facto standard maildrop format on Unix,
1804 whereas the MMDF maildrop format is hardly still known today.
1805 I did drop MMDF maildrop format support.
1806 .P
1807 The simplifications within the code were only moderate.
1808 Switches could be removed from
1809 .L packf
1810 and
1811 .L rcvpack ,
1812 which generate packed mailboxes.
1813 Only one packed mailbox format remained: mbox.
1814 The more important changes affected the equally named mail parsing
1815 routine in
1816 .Fn sbr/m_getfld.c .
1817 The MMDF code had been removed there, but as now only one packed mailbox
1818 format is left, further code structure simplifications may be possible.
1819 I have not worked on them yet because
1820 .Fu m_getfld()
1821 is heavily optimized and thus dangerous to touch.
1822 The risk of damaging the intricate workings of the optimized code is
1823 too high.
1824 .\" XXX: move somewhere else
1825 This problem is know to the developers of nmh, too.
1826 They also avoid touching this minefield if possible.
1827
1779 1828
1780 .U3 "Prompter's Control Keys 1829 .U3 "Prompter's Control Keys
1781 .P 1830 .P
1782 The program 1831 The program
1783 .Pn prompter 1832 .Pn prompter
1784 queries the user to fill in a message form. When used by 1833 queries the user to fill in a message form.
1834 When used by
1785 .Pn comp 1835 .Pn comp
1786 as: 1836 as
1787 .VS 1837 .Cl "comp -editor prompter" ,
1788 comp -editor prompter
1789 VE
1790 the resulting behavior is similar to 1838 the resulting behavior is similar to
1791 .Pn mailx . 1839 .Pn mailx .
1792 Apparently, 1840 Apparently,
1793 .Pn prompter 1841 .Pn prompter
1794 hadn't been touched lately. Otherwise it's hardly explainable why it 1842 hadn't been touched lately.
1843 Otherwise it's hardly explainable why it
1795 still offered the switches 1844 still offered the switches
1796 .Sw -erase 1845 .Sw -erase
1797 .Ar chr 1846 .Ar chr
1798 and 1847 and
1799 .Sw -kill 1848 .Sw -kill
1801 to name the characters for command line editing. 1850 to name the characters for command line editing.
1802 The times when this had been necessary are long time gone. 1851 The times when this had been necessary are long time gone.
1803 Today these things work out-of-the-box, and if not, are configured 1852 Today these things work out-of-the-box, and if not, are configured
1804 with the standard tool 1853 with the standard tool
1805 .Pn stty . 1854 .Pn stty .
1806 1855 The switches are removed now
1807 .U3 "Vfork and Retry Loops 1856 .Ci 0bd9750710cdbab80cfb4036dd87af20afe1552f .
1808 .P 1857
1809 MH creates many processes, which is a consequence of the tool chest approach. 1858
1810 In earlier times 1859 .U3 "Hardcopy terminal support
1811 .Fu fork() 1860 .P
1812 had been an expensive system call, as the process's whole image needed 1861 More of a funny anecdote is a check for printing to a
1813 to be duplicated. One common case is replacing the image with 1862 hardcopy terminal that remained in the code until Spring 2012,
1814 .Fu exec() 1863 when I finally removed it
1815 right after having forked the child process. 1864 .Ci b7764c4a6b71d37918a97594d866258f154017ca .
1816 To speed up this case, the 1865 I surely would be very happy to see such a terminal in action,
1817 .Fu vfork() 1866 maybe actually being able to work on it, but I fear my chances are null.
1818 system call was invented at Berkeley. It completely omits copying the 1867 .P
1819 image. If the image gets replaced right afterwards then unnecessary 1868 The check only prevented a pager to be placed between the outputting
1820 work is omited. On old systems this results in large speed ups. 1869 program (\c
1821 MH uses 1870 .Pn mhl )
1822 .Fu vfork() 1871 and the terminal.
1823 whenever possible. 1872 In nmh, this could have been ensured with the
1824 .P 1873 .Sw -nomoreproc
1825 Memory management units that support copy-on-write semantics make 1874 at the command line statically, too.
1826 .Fu fork() 1875 In mmh, set the profile entry
1827 almost as fast as 1876 .Pe Pager
1828 .Fu vfork() 1877 or the environment variable
1829 in the cases when they can be exchanged. 1878 .Ev PAGER
1830 With 1879 to
1831 .Fu vfork() 1880 .Pn cat .
1832 being more error-prone and hardly faster, it's preferable to simply 1881
1833 use 1882
1834 .Fu fork()
1835 instead.
1836 .P
1837 Related to the costs of
1838 .Fu fork()
1839 is the probability of its success.
1840 Today on modern systems, the system call will succeed almost always.
1841 In the Eighties on heavy loaded systems, as they were common at
1842 universities, this had been different. Thus, many of the
1843 .Fu fork()
1844 calls were wrapped into loops to retry to fork several times in
1845 short intervals, in case of previous failure.
1846 In mmh, the program aborts at once if the fork failed.
1847 The user can reexecute the command then. This is expected to be a
1848 very rare case on modern systems, especially personal ones, which are
1849 common today.
1850 1883
1851 1884
1852 .H2 "Attachments 1885 .H2 "Attachments
1853 .P 1886 .P
1854 The mind model of email attachments is unrelated to MIME. 1887 The mind model of email attachments is unrelated to MIME.
2129 these facts, I rather let people with more historic experience solve the 2162 these facts, I rather let people with more historic experience solve the
2130 task of converting the ancient code constructs to standardized ones. 2163 task of converting the ancient code constructs to standardized ones.
2131 Luckily, Lyndon Nerenberg focused on this task at the nmh project. 2164 Luckily, Lyndon Nerenberg focused on this task at the nmh project.
2132 He converted large parts of the code to POSIX constructs, removing 2165 He converted large parts of the code to POSIX constructs, removing
2133 the conditionals compilation for now standardized features. 2166 the conditionals compilation for now standardized features.
2134 I'm thankful for this task being solved. I only pulled the changes into 2167 I'm thankful for this task being solved.
2168 I only pulled the changes into
2135 mmh. 2169 mmh.
2136 2170
2137 2171
2138 2172
2139 2173
2144 In MH and nmh, a personal setup had consisted of two parts: 2178 In MH and nmh, a personal setup had consisted of two parts:
2145 The MH profile, named 2179 The MH profile, named
2146 .Fn \&.mh_profile 2180 .Fn \&.mh_profile
2147 and being located directly in the user's home directory. 2181 and being located directly in the user's home directory.
2148 And the MH directory, where all his mail messages and also his personal 2182 And the MH directory, where all his mail messages and also his personal
2149 forms, scan formats, other configuration files are stored. The location 2183 forms, scan formats, other configuration files are stored.
2150 of this directory could be user-chosen. The default was to name it 2184 The location
2185 of this directory could be user-chosen.
2186 The default was to name it
2151 .Fn Mail 2187 .Fn Mail
2152 and have it directly in the home directory. 2188 and have it directly in the home directory.
2153 .P 2189 .P
2154 I've never liked the data storage and the configuration to be intermixed. 2190 I've never liked the data storage and the configuration to be intermixed.
2155 They are different kinds of data. One part, are the messages, 2191 They are different kinds of data.
2156 which are the data to operate on. The other part, are the personal 2192 One part, are the messages,
2193 which are the data to operate on.
2194 The other part, are the personal
2157 configuration files, which are able to change the behavior of the operations. 2195 configuration files, which are able to change the behavior of the operations.
2158 The actual operations are defined in the profile, however. 2196 The actual operations are defined in the profile, however.
2159 .P 2197 .P
2160 When storing data, one should try to group data by its type. 2198 When storing data, one should try to group data by its type.
2161 There's sense in the Unix file system hierarchy, where configuration 2199 There's sense in the Unix file system hierarchy, where configuration
2173 Still there are two places: 2211 Still there are two places:
2174 There's the mail storage directory, which, like in MH, contains all the 2212 There's the mail storage directory, which, like in MH, contains all the
2175 messages, but, unlike in MH, nothing else. 2213 messages, but, unlike in MH, nothing else.
2176 Its location still is user-chosen, with the default name 2214 Its location still is user-chosen, with the default name
2177 .Fn Mail , 2215 .Fn Mail ,
2178 in the user's home directory. This is much similar to the case in nmh. 2216 in the user's home directory.
2217 This is much similar to the case in nmh.
2179 The configuration files, however, are grouped together in the new directory 2218 The configuration files, however, are grouped together in the new directory
2180 .Fn \&.mmh 2219 .Fn \&.mmh
2181 in the user's home directory. 2220 in the user's home directory.
2182 The user's profile now is a file, named 2221 The user's profile now is a file, named
2183 .Fn profile , 2222 .Fn profile ,
2186 and the like, are also there. 2225 and the like, are also there.
2187 .P 2226 .P
2188 The naming changed with the relocation. 2227 The naming changed with the relocation.
2189 The directory where everything, except the profile, had been stored (\c 2228 The directory where everything, except the profile, had been stored (\c
2190 .Fn $HOME/Mail ), 2229 .Fn $HOME/Mail ),
2191 used to be called \fIMH directory\fP. Now, this directory is called the 2230 used to be called \fIMH directory\fP.
2192 user's \fImail storage\fP. The name \fImmh directory\fP is now given to 2231 Now, this directory is called the
2232 user's \fImail storage\fP.
2233 The name \fImmh directory\fP is now given to
2193 the new directory 2234 the new directory
2194 (\c 2235 (\c
2195 .Fn $HOME/.mmh ), 2236 .Fn $HOME/.mmh ),
2196 containing all the personal configuration files. 2237 containing all the personal configuration files.
2197 .P 2238 .P
2198 The separation of the files by type of content is logical and convenient. 2239 The separation of the files by type of content is logical and convenient.
2199 There are no functional differences as any possible setup known to me 2240 There are no functional differences as any possible setup known to me
2200 can be implemented with both approaches, although likely a bit easier 2241 can be implemented with both approaches, although likely a bit easier
2201 with the new approach. The main goal of the change had been to provide 2242 with the new approach.
2243 The main goal of the change had been to provide
2202 sensible storage locations for any type of personal mmh file. 2244 sensible storage locations for any type of personal mmh file.
2203 .P 2245 .P
2204 In order for one user to have multiple MH setups, he can use the 2246 In order for one user to have multiple MH setups, he can use the
2205 environment variable 2247 environment variable
2206 .Ev MH 2248 .Ev MH
2224 .Ev MMHC 2266 .Ev MMHC
2225 change the profile and context files, respectively. 2267 change the profile and context files, respectively.
2226 Besides providing a more consistent feel (which simply is the result 2268 Besides providing a more consistent feel (which simply is the result
2227 of being designed anew), the set of personal configuration files can 2269 of being designed anew), the set of personal configuration files can
2228 be chosen independently from the profile (including mail storage location) 2270 be chosen independently from the profile (including mail storage location)
2229 and context, now. Being it relevant for practical use or not, it 2271 and context, now.
2230 de-facto is an improvement. However, the main achievement is the 2272 Being it relevant for practical use or not, it
2273 de-facto is an improvement.
2274 However, the main achievement is the
2231 split between mail storage and personal configuration files. 2275 split between mail storage and personal configuration files.
2232 2276
2233 2277
2234 .H2 "Modularization 2278 .H2 "Modularization
2235 .P 2279 .P
2258 .H2 "Draft Folder 2302 .H2 "Draft Folder
2259 .P 2303 .P
2260 Historically, MH provided exactly one draft message, named 2304 Historically, MH provided exactly one draft message, named
2261 .Fn draft 2305 .Fn draft
2262 and 2306 and
2263 being located in the MH directory. When starting to compose another message 2307 being located in the MH directory.
2308 When starting to compose another message
2264 before the former one was sent, the user had been questioned whether to use, 2309 before the former one was sent, the user had been questioned whether to use,
2265 refile or replace the old draft. Working on multiple drafts at the same time 2310 refile or replace the old draft.
2266 was impossible. One could only work on them in alteration by refiling the 2311 Working on multiple drafts at the same time
2267 previous one to some directory and fetching some other one for reediting. 2312 was impossible.
2313 One could only work on them in alteration by refiling the
2314 previous one to some directory and fetching some other one for reediting.
2268 This manual draft management needed to be done each time the user wanted 2315 This manual draft management needed to be done each time the user wanted
2269 to switch between editing one draft to editing another. 2316 to switch between editing one draft to editing another.
2270 .P 2317 .P
2271 To allow true parallel editing of drafts, in a straight forward way, the 2318 To allow true parallel editing of drafts, in a straight forward way, the
2272 draft folder facility exists. It had been introduced already in July 1984 2319 draft folder facility exists.
2273 by Marshall T. Rose. The facility was deactivated by default. 2320 It had been introduced already in July 1984
2321 by Marshall T. Rose.
2322 The facility was deactivated by default.
2274 Even in nmh, the draft folder facility remained deactivated by default. 2323 Even in nmh, the draft folder facility remained deactivated by default.
2275 At least, Richard Coleman added the man page 2324 At least, Richard Coleman added the man page
2276 .Mp mh-draft(5) 2325 .Mp mh-draft(5)
2277 to document 2326 to document
2278 the feature well. 2327 the feature well.
2279 .P 2328 .P
2280 The only advantage of not using the draft folder facility is the static 2329 The only advantage of not using the draft folder facility is the static
2281 name of the draft file. This could be an issue for MH front-ends like mh-e. 2330 name of the draft file.
2331 This could be an issue for MH front-ends like mh-e.
2282 But as they likely want to provide working on multiple drafts in parallel, 2332 But as they likely want to provide working on multiple drafts in parallel,
2283 the issue is only concerning compatibility. The aim of nmh to stay compatible 2333 the issue is only concerning compatibility.
2334 The aim of nmh to stay compatible
2284 prevented the default activation of the draft folder facility. 2335 prevented the default activation of the draft folder facility.
2285 .P 2336 .P
2286 On the other hand, a draft folder is the much more natural concept than 2337 On the other hand, a draft folder is the much more natural concept than
2287 a draft message. MH's mail storage consists of folders and messages, 2338 a draft message.
2288 the messages named with ascending numbers. A draft message breaks with this 2339 MH's mail storage consists of folders and messages,
2340 the messages named with ascending numbers.
2341 A draft message breaks with this
2289 concept by introducing a message in a file named 2342 concept by introducing a message in a file named
2290 .Fn draft . 2343 .Fn draft .
2291 This draft 2344 This draft
2292 message is special. It can not be simply listed with the available tools, 2345 message is special.
2293 but instead requires special switches. I.e. corner-cases were 2346 It can not be simply listed with the available tools,
2294 introduced. A draft folder, in contrast, does not introduce such 2347 but instead requires special switches.
2295 corner-cases. The available tools can operate on the messages within that 2348 I.e. corner-cases were
2296 folder like on any messages within any mail folders. The only difference 2349 introduced.
2350 A draft folder, in contrast, does not introduce such
2351 corner-cases.
2352 The available tools can operate on the messages within that
2353 folder like on any messages within any mail folders.
2354 The only difference
2297 is the fact that the default folder for 2355 is the fact that the default folder for
2298 .Pn send 2356 .Pn send
2299 is the draft folder, 2357 is the draft folder,
2300 instead of the current folder, like for all other tools. 2358 instead of the current folder, like for all other tools.
2301 .P 2359 .P
2302 The trivial part of the change was activating the draft folder facility 2360 The trivial part of the change was activating the draft folder facility
2303 by default and setting a default name for this folder. Obviously, I chose 2361 by default and setting a default name for this folder.
2362 Obviously, I chose
2304 the name 2363 the name
2305 .Fn +drafts . 2364 .Fn +drafts .
2306 This made the 2365 This made the
2307 .Sw -draftfolder 2366 .Sw -draftfolder
2308 and 2367 and
2316 operating on any other message for the tools. 2375 operating on any other message for the tools.
2317 .Pn comp 2376 .Pn comp
2318 still has its 2377 still has its
2319 .Sw -use 2378 .Sw -use
2320 switch for switching between its two modes: (1) Compose a new 2379 switch for switching between its two modes: (1) Compose a new
2321 draft, possibly by taking some existing message as a form. (2) Modify 2380 draft, possibly by taking some existing message as a form.
2322 an existing draft. In either case, the behavior of 2381 (2) Modify
2382 an existing draft.
2383 In either case, the behavior of
2323 .Pn comp is 2384 .Pn comp is
2324 deterministic. There is no more need to query the user. I consider this 2385 deterministic.
2325 a major improvement. By making 2386 There is no more need to query the user.
2387 I consider this
2388 a major improvement.
2389 By making
2326 .Pn send 2390 .Pn send
2327 simply operate on the current 2391 simply operate on the current
2328 message in the draft folder by default, with message and folder both 2392 message in the draft folder by default, with message and folder both
2329 overridable by specifying them on the command line, it is now possible 2393 overridable by specifying them on the command line, it is now possible
2330 to send a draft anywhere within the storage by simply specifying its folder 2394 to send a draft anywhere within the storage by simply specifying its folder
2335 2399
2336 2400
2337 .H2 "Trash Folder 2401 .H2 "Trash Folder
2338 .P 2402 .P
2339 Similar to the situation for drafts is the situation for removed messages. 2403 Similar to the situation for drafts is the situation for removed messages.
2340 Historically, a message was deleted by renaming. A specific 2404 Historically, a message was deleted by renaming.
2405 A specific
2341 \fIbackup prefix\fP, often comma (\c 2406 \fIbackup prefix\fP, often comma (\c
2342 .Fn , ) 2407 .Fn , )
2343 or hash (\c 2408 or hash (\c
2344 .Fn # ), 2409 .Fn # ),
2345 being prepended to the file name. Thus, MH wouldn't recognize the file 2410 being prepended to the file name.
2411 Thus, MH wouldn't recognize the file
2346 as a message anymore, as only files whose name consists of digits only 2412 as a message anymore, as only files whose name consists of digits only
2347 are treated as messages. The removed messages remained as files in the 2413 are treated as messages.
2414 The removed messages remained as files in the
2348 same directory and needed some maintenance job to truly delete them after 2415 same directory and needed some maintenance job to truly delete them after
2349 some grace time. Usually, by running a command similar to 2416 some grace time.
2417 Usually, by running a command similar to
2350 .VS 2418 .VS
2351 find /home/user/Mail -ctime +7 -name ',*' | xargs rm 2419 find /home/user/Mail -ctime +7 -name ',*' | xargs rm
2352 VE 2420 VE
2353 in a cron job. Within the grace time interval 2421 in a cron job.
2422 Within the grace time interval
2354 the original message could be restored by stripping the 2423 the original message could be restored by stripping the
2355 the backup prefix from the file name. If however, the last message of 2424 the backup prefix from the file name.
2425 If however, the last message of
2356 a folder is been removed \(en say message 2426 a folder is been removed \(en say message
2357 .Fn 6 2427 .Fn 6
2358 becomes file 2428 becomes file
2359 .Fn ,6 2429 .Fn ,6
2360 \(en and a new message enters the same folder, thus the same 2430 \(en and a new message enters the same folder, thus the same
2375 .Pe Delete-Prog ) 2445 .Pe Delete-Prog )
2376 was introduced, very early. 2446 was introduced, very early.
2377 It could be set to any command, which would care for the mail removal 2447 It could be set to any command, which would care for the mail removal
2378 instead of taking the default action, described above. 2448 instead of taking the default action, described above.
2379 Refiling the to-be-removed files to some garbage folder was a common 2449 Refiling the to-be-removed files to some garbage folder was a common
2380 example. Nmh's man page 2450 example.
2451 Nmh's man page
2381 .Mp rmm(1) 2452 .Mp rmm(1)
2382 proposes 2453 proposes
2383 .Cl "refile +d 2454 .Cl "refile +d
2384 to move messages to the garbage folder and 2455 to move messages to the garbage folder and
2385 .Cl "rm `mhpath +d all` 2456 .Cl "rm `mhpath +d all`
2386 the empty the garbage folder. 2457 the empty the garbage folder.
2387 Managing the message removal this way is a sane approach. It keeps 2458 Managing the message removal this way is a sane approach.
2459 It keeps
2388 the removed messages in one place, makes it easy to remove the backup 2460 the removed messages in one place, makes it easy to remove the backup
2389 files, and, most important, enables the user to use the tools of MH 2461 files, and, most important, enables the user to use the tools of MH
2390 itself to operate on the removed messages. One can 2462 itself to operate on the removed messages.
2463 One can
2391 .Pn scan 2464 .Pn scan
2392 them, 2465 them,
2393 .Pn show 2466 .Pn show
2394 them, and restore them with 2467 them, and restore them with
2395 .Pn refile . 2468 .Pn refile .
2397 need to use 2470 need to use
2398 .Pn mhpath 2471 .Pn mhpath
2399 to switch over from MH tools to Unix tools \(en MH can do it all itself. 2472 to switch over from MH tools to Unix tools \(en MH can do it all itself.
2400 .P 2473 .P
2401 This approach matches perfect with the concepts of MH, thus making 2474 This approach matches perfect with the concepts of MH, thus making
2402 it powerful. Hence, I made it the default. And even more, I also 2475 it powerful.
2476 Hence, I made it the default.
2477 And even more, I also
2403 removed the old backup prefix approach, as it is clearly less powerful. 2478 removed the old backup prefix approach, as it is clearly less powerful.
2404 Keeping unused alternative in the code is a bad choice as they likely 2479 Keeping unused alternative in the code is a bad choice as they likely
2405 gather bugs, by not being constantly tested. Also, the increased code 2480 gather bugs, by not being constantly tested.
2406 size and more conditions crease the maintenance costs. By strictly 2481 Also, the increased code
2482 size and more conditions crease the maintenance costs.
2483 By strictly
2407 converting to the trash folder approach, I simplified the code base. 2484 converting to the trash folder approach, I simplified the code base.
2408 .Pn rmm 2485 .Pn rmm
2409 calls 2486 calls
2410 .Pn refile 2487 .Pn refile
2411 internally to move the to-be-removed 2488 internally to move the to-be-removed
2412 message to the trash folder (\c 2489 message to the trash folder (\c
2413 .Fn +trash 2490 .Fn +trash
2414 by default). Messages 2491 by default).
2492 Messages
2415 there can be operated on like on any other message in the storage. 2493 there can be operated on like on any other message in the storage.
2416 The sweep clean, one can use 2494 The sweep clean, one can use
2417 .Cl "rmm -unlink +trash a" , 2495 .Cl "rmm -unlink +trash a" ,
2418 where the 2496 where the
2419 .Sw -unlink 2497 .Sw -unlink