Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Paul Vixie]

Lyndon Nerenberg wrote:

On Feb 19, 2014, at 8:22 AM, address@hidden wrote:

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.

MH is not resource constrained by CPU, or memory for that matter, so I would change nothing.

i would. first, i'd adopt the messages-as-directories model norm gave, since it supports MIME, where our current model does not. by "support" i mean i want to use normal UNIX file access to work with my message store. there is no file-level access to attachments right now, which means i have to run "mhstore" to turn an opaque black-box attachment into a UNIX file i can access. mhstore is highly impure by MH's overall design principles, even though i'm grateful to have it under the circumstances.

second, i'd put all of MH's folder and message and reception and transmission logic into a library. this library would be fast and well documented even though it might make huge use of the heap which would have made it impractical in the PDP 11/45 era. all MH command line utilities would be UI wrappers around this fast portable well documented library. we would encourage languages beyond C to skin our API so that it could be directly called by perl, python, php, e-lisp, and so on. the definition of "MH aware" would add "uses MH's library" to the other elements already present ("can access things using normal UNIX file methods", and "knows how to execute MH commands and parse their output". mh-e would become a library client that would almost never have to call "popen".

third and finally, i'd fully support the IMAP "UID" psychosis, by offering persistent-for-the-life-of-the-message numeric identifiers, and i'd add code to the library and UI elements to the command set to access things that way. an IMAP server should be able to link to the MH library and everything should just work.

note well: this is practical today, as long as we can still access old style folders as well, and as long as we offer some kind of FUSE interface (for systems who have FUSE or similar) to allow new-style folders to be accessed with old-style tools.

vixie