Re: [Nmh-workers] IMAP/nmh, again

[Ken Hornstein]

>the top of thread shows a prediction of likely performance impact from 
>opening and closing an imap session every time an mh command starts or 
>stops. i'm arguing against that, because state is necessary in order to 
>receive push notifications, and so to me, the reason to keep one long 
>lived imap connection open is more important than the performance we 
>could achieve without doing so.

I'm not AGAINST a longer-lived daemon, but ... well, it's more
complicated.  I mean, we need to write the IMAP protocol engine
regardless of what we do; putting an additional abstraction layer
would be a whole other pile of code (also, I'm not sure that the
client<->daemon protocol wouldn't end up looking a lot like IMAP).  And
the helper daemons you mention (ssh-agent and gpg-agent) are not quite
the same; they are adjuncts designed to hold authentication credentials
so users don't have to keep typing in passwords.

With the "almost no caching" model, things are much simpler; I mean, it's
not like you get notified in a traditional MH mailstore that new messages
have arrived.  I'm not sure you really need push notifications, unless
I am not understanding your ultimate goal (which is always possible).

And yes, it is easy to come up with issues that make this implementation
less than perfect.  For example, assume that the UID-message number
mapping is stored somewhere in ~/Mail.  This means on systems without
a shared home directory, every nmh instance would have it's own message
number mapping (I would argue this is exactly how it is TODAY).  Arbitrary
sequences are a challenge unless the server allows unlimited flags, and
not all do.  Annotations (other than a basic "this was replied to") are
VERY difficult.  I feel these tradeoffs are certainly worth it for
at least some kind of IMAP support, but of course if you do not agree
then you are free to not use it!  Or at the very least, use "refile" to
bring the messages from your IMAP store into a local nmh store where you
can get full functionality.

>yes but i was envisioning an nmh-agent that abstracted all operations on 
>mh objects that would otherwise require locking -- not just keeping an 
>imap connection open for various mh commands to re-use. bad vixie.

I ... can VAGUELY see how that might be useful.  It's just ... finite
amount of time!  Let me say that I'm not envisioning doing anything that
would PRECLUDE such a thing.  We can target it for the nmh IMAP v2
implementation :-)

--Ken