Lyndon Nerenberg wrote:
On Feb 19, 2014, at 8:22 AM, norm(_at_)dad(_dot_)org 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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers