Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

[Paul Vixie]

Ken Hornstein wrote:
> Here is my $0.02 on that topic.
>
> ...

strong +1 to ken's analysis here, and below where he questioned the 
utility of developing our own IMAP server. in more detail, this topic:

> Now I am not suggesting that we replace the MH mailstore with Maildir;
> that doesn't seem such a great idea to me.  But supporting Maildir and
> IMAP sure seems like a no-brainer to me; that makes nmh MORE USEFUL to
> people.  That gains us interoperability with other clients, and that
> means people aren't stuck with just using nmh, they can use whatever
> MUA they want in addition to nmh.

i liked your mapping idea of remembering that a MH message number 
actually refers to something else, like an IMAP UID, or a Maildir file.

implementation-wise, the code base thinks in POSIX. it knows about 
directory names, folder pathnames, file basenames, file pathnames, and 
file descriptors (from which are then often made FILE handles.) if we 
could make a correctness-preserving transformation that hid all of the 
POSIX naming details, then the resulting code would only know about 
folder names, message numbers, file descriptors, and maybe FILE handles.

initially there would be a "nullfs" style implementation of the new 
middleware, where opaque handles could be created to refer to some 
folder or to some message, with constructors that took "const char *" 
for folder names and "int" for message numbers, by dint of just 
asprintf() much as the code does today. a VFS-like set of methods that 
did what open(), remove(), rename() all did, such that the _only_ part 
of the nmh code base that made the POSIX file-related system calls was 
the "nullfs" layer.

from there, implementing Maildir might be easier than from here. even 
IMAP isn't impossible, if we're willing to return a socket descriptor 
instead of a file descriptor, or maybe a pipe from a fork, or (gag me) a 
temporary file.

--
P Vixie