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

[Paul Vixie]

Ken Hornstein wrote:
> > 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).

netcat is enough. its license is such that we could butcher a copy of 
it. it would:

connect to the imap service and authenticate
open a unix domain socket and listen() to it
on each connection:
-> if there are no other connections, proxy betw. unix domian and imap
-> else, return a "we're busy, come back later" indication

now, adding logic to some day send IDLE and process asynchronous events 
in the way shown at <https://en.wikipedia.org/wiki/IMAP_IDLE> is work 
for some later day.

also, adding multiple concurrent work streams per imap session. also, 
adding multiple concurrent imap sessions. also, opening imap sessions to 
more than just one server (since some folders will be elsewhere.)

so, yes, its protocol would look exactly like imap, because it would be 
proxied. note that we can't dup() the imap connection and pass that file 
descriptor over the unix domain socket, because of TLS.

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

actually, they're the same, because some of us type our imap passwords 
every time we connect, and won't want them stored in .mh_profile.

the part of mh that wants to connect to imap would try to find the unix 
domain socket, and if it wasn't present it could optionally, or prompt 
before doing so, or recommend that the user, launch the agent and then 
connect to it. i would like to have a default path name so that if there 
is no environment variable, the service can still be reached.

> > 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 :-)

or we can do the above as v1, leaving code points in the 
connect-to-proxy api and protocol so as to select by default "i want to 
talk to the imap connection", or later on, select "i want to talk to the 
indexer" or "i want the list of folders, or messages, or whatever."

--
P Vixie