[email protected] writes: > I am suggesting this exercise only for recreational purposes. > > Design MH, from scratch, without the constraints affecting the original > MH design. > Suppose, you weren't designing a system to run on a time shared PDF 1145, > but on a > single user, multi-core system. Suppose that you had multi gigabyte disks > available. But also suppose you had to worry about distributed data and > processing. > But, mostly importantly, suppose that you didn't have to worry about > being too radical for acceptance. > > What, then. would MH look like? > > Here, for example, is one stab at how messages would be stored. > Each message would be a directory. Each component would be a file or > directory, > whose name was the component name, Each MIME part would be a directory.
The design of my future mail reader will be as follows: mail is stored in Maildir (read-only support for Mailboxes is available, too). Maildir support allows me to use offlineimap to sync against an IMAP store. However, for reading the *results of query* against the store (for now, I use mairix for this), such as "all new/unread mail", "all mail matching $words" etc. will be rendered into trees like this: idx cur -> 1/ 1/raw -> /home/chris/Mail/INBOX/cur/1343755814_1.9959.juno,U=623,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S 1/text 2/raw -> /home/chris/Mail/INBOX/cur/1343755654_3.9959.juno,U=544,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S 2/text 3/raw -> /home/chris/Mail/INBOX/cur/1343755143_0.9959.juno,U=131,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S 3/text 4/0 4/0/0 4/0/1 4/0/2 4/1 4/musicextras-gui.po -> 0/2 4/musicextras.po -> 0/1 4/raw -> /home/chris/Mail/INBOX/cur/1343755102_3.9959.juno,U=89,FMD5=7e33429f656f1e6e9d79b29c3f8 The file "idx" contains the sender and subject data, easily sortable by various keys (date, from, subject, threaded), as well as the imap flags. (i.e. like a cache of MH scan(1)). The "text" contains a rendered version (roughly like mhshow) of the mail kept in "raw" (for mbox, this is generated, for Maildir, it's just a symlink). HTML is rendered with w3m or lynx, for zip files there is a table of contents etc. MIME attachments are readily expanded into files (e.g. message 4), so you can apply patches directly or look at attached pictures. MH-style tools operate on these trees. next/prev update the "cur" symlink to keep track. Updating message flags like read/replied/trash directly operate on the Maildir, but also update the rendered tree (yet tbd). I'm not yet sure about other sequences (they could be realized as lists of Maildir files, but then they need to be updated on flag changes...) These trees are ephemeral, when I'm done reading them they will be deleted. Rendering them is plenty fast, reading is instant (I keep them in an tmpfs, even). You can have several trees in different directories (probably an environment variable will choose the current one, or it will check if $PWD is one). You can also render them from procmail or cron if you really want instant mail reading. The system is about 2/3 done so far and essentially consists of a <1KLOC Ruby script (with no foreign dependencies) and a bunch of shell scripts and aliases. The mechanic is really simple. Currently, I'm considering (ab)using vi(m) as an interface for reading many mails quickly. vim macros are easy to bind to keys, can run external commands and show their output, and provide split windows. I have been thinking about this for years now and tried various other ideas already. Please ask if anything is unclear. -- Christian Neukirchen <[email protected]> http://chneukirchen.org _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
