> I had envisaged an IMAP server which would implement
> the nmh commands as an interface to the "message store", but the client side
> would be left open to "anything that supports IMAP".
Now I get it. I think having separate files/message would be a big
win on the server because now you don't have to worry about seeking
through multi-megabytes of a mail file, and constantly keeping track
of the current message, etc. If the user asks for message 330, do a
quick stat in the correct inbox, and bam, you're ready to start writing
data to a socket. Compared to a single-file approach, the
server would either need to read through the file and find
329 start points and then start writing (dumb), or create an
index of message => offests when it first starts up. Technically the
server could store this index so you don't need to do this much
parsing every time, but when you do, it's a pain.
I think mh-style mailboxes would make that easier. I don't know if
implementing a mail server *entirely* in nmh commands owuld work/be a
good idea, but damn would it be a neat trick - write a mail server
using mail client programs...
> I future step could be to implement IMAP in exmh, which could make
> support for sequences more pertinent, but raises raises another concern;
> how would sequences be handled when talking to an IMAP server that
> wasn't our "nmh-ified" one? Wouldn't it be more correct to just stick to the
> IMAP standard?
Yes, stick to the standard. If you think there would be features talking
to an "nmh" mail server, I would suggest writing a suite of 100-line
client programs called `inc', `scan', `forw', `repl', etc., that
open a socket to a specified server, send the text of a command to run,
have the server execute it as the user in question, and then return
the result to the user. Doing this all over IMAP seems to be
kludgy, and you'll use the most important features.
Shantonu
