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
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers