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

[Ken Hornstein]

>. OK [READ-WRITE] Select completed (2.203 + 0.000 + 2.202 secs).

When I was poking around on the Cyrus server, I found that the times
it reported didn't match what I saw (they were longer).  But, let's
say this is probably pretty close; since this is your IMAP server, I'd
be interested why this variance occurs.  You would think for the same
mailbox it would always be the same.  Since you say that it "often"
takes much less than a second, I am wondering if maybe that only happens
when new mail arrives and Dovecot needs to rescan the directory.  The
Cyrus IMAP server took on the order of 17-35 msec to perform a SELECT on
a mailbox with 5x of the messages in it.  That seems like a pretty large
performance gap.

But, hey, I fully admit I tried this on ONE IMAP server!  So, more data
is always welcome.  I eventually want to upload a ton of messages to
the Google IMAP server and see how some of those operations do.

>The trickier aspect, and the real issue for me, is proper
>synchronization when email is accessed from multiple machines, and which
>may not be connected all the time. On reconnection a client has to
>upload its changes and resync its local cache with the imap server so
>that changes made elsewhere are properly reflected.

Well, that's why I was advocating a solution, which I guess I would
call "almost no caching".

All that is cached locally is the mapping between the UID and the MH
message number.  If you need some data, you fetch it from the the IMAP
server as requested.  As shown previously, this doesn't seem to take a
lot of time at least in the one example I tried.  If you are accessing
email on a commercially-provided IMAP server, I suspect it's going to
be pretty good.  Other operations (e.g., rmm, mkf) are just performed
immediately as you do them.  The only "syncing" you need to do is check
to see if there are new messages in the mailbox, and if there are it is
pretty easy to fetch the new UIDs and assign them MH message numbers
(deleted messages are mildly harder, but really, not hugely so; you just
have to fetch the whole UID list and figure out which ones are missing).

>So my current strategy is to wrap unchanged MH commands or rewrite the
>simpler ones which are more the "plumbing" kind, for example, mhpath and
>mhparam.

Well, I do look forward to seeing what you implement!  Please keep us
in the loop.

--Ken