Re: [Nmh-workers] MH + IMAP? (was Large MH directories

[Ken Hornstein]

>If common MH commands have to connect to an imap server & login every
>time, people will notice the delay. May make sense to have a local
>imap<->MH daemon. You then connect to it over a local socket. The daemon
>makes it easy to add caching.

That HAS been discussed, but .... well, it increases the complexity.
Not only do you have to write the code to talk to the IMAP server, but you
also have to write the daemon code to talk between the nmh utilities and
your local daemon.  Some issues that pop out with me is how to determine
the name of the local socket to communicate and security.  These are
probably solvable, but increase complexity.

As for the delay ... well, my experience with message submission which
involved authenticating to SMTP servers using similar protocols to IMAP
showed me that a complete message submission took between 0.3 and 0.7
seconds.  This was over the global Internet, and involved a number of
round-trips.  That's not imperceptible, but I think it's perfectly
acceptable.  We can make use of IMAPs command pipelining and ability to
only extract parts of messags to make some intelligent decisions to
reduce network traffic.  I think this is a case of, "Maybe it won't be
so bad, but we'd have to actually try it to see".

>I think mh-imap daemon V1 as outlined above would require very few
>changes in nmh proper. Basically you have to tell mh-imap when you
>perform any operation that changes the message number mapping (or let
>it do it for you). But it doesn't care what is your current folder or
>current message or which sequences you have defined.

Unless you want to have to trawl all of the folders, I think you'd have
to have the nmh utilities talk to the daemon to make sure the folder
was up-to-date.

>One problem I see is if multiple mh<->imap clients (however we implement
>them) are concurrently accessing the same remote message store and
>decide to map message-IDs to local message numbers differently. It
>may be possible to abuse the IMAP protocol to implement nonblocking
>synchronization!

We could simply define the interface (at least in the first iteration)
that message numbers are not the same between nmh instances.

>Thanks for your comments. Looks like this is feasible and, may be, not
>too hard. I'll try to find some time to prototype this. There a number
>of open source imap clients in Go that may make a good starting point.

I would caution you that many people have started this work, but have
abandoned the attempt because they got busy; I'd start with the simplest
implementation you could get away with and build on it over time.

--Ken