>. 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 _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
