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

[Bakul Shah]

On Oct 14, 2017, at 10:57 PM, Ken Hornstein <address@hidden> wrote:
> 
>> 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.

The local socket part is easy. Connect to /tmp/mhd/$USER.
[Calling this daemon mhd for short] If the socket doesn't
exist or a write to it fails, kick off mhd.

I think the decision to cache things locally or not is a
separate one from whether to have a proxy such as mhd.  I
think eventually we would want local caching -- imap access is
is pretty slow. At home I have my imap server and my laptop on
the same subnet but even so the access is rather slow. And try
accessing imap from your laptop using your phone as a hotspot!
It is slow enough that pretty much every imap client I have
used caches messages locally.

Second, an nmh command can be interrupted at any time, while a
daemon can hang around and only exit when it is safe to do so.

Third, the imap server can make changes (e.g. deleting old
messages) or access from another computer can change things.
These changes have to be propagated to the local machine and
that too can take time.

Given all this it makes sense to me to start with the model of
of a separate daemon. I think interfacing nmh commands with mhd
will be much simpler than interfacing with a remote imap server.

Of course, there are just some initial thoughts. I reread the
rfc3501 last night to better understand the IMAP protocol but 
I'll have to write some sample code and feel my way around.

>> 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.

Yes. Any command that can add/delete/move folders and messsages
will have to talk to mhd. But pick, show, scan don't need to.`

> 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.


Hopefully discussing & documenting the design & generating some
interest + starting with an existing imap client improve the
odds of success. I will put up my notes on github soon + any code
as I write it. At a minimum I want inc working!