[Imap-protocol] Re: Efficiently handling sequence numbers

On Friday, 9 November 2012 23:16:19 CEST, Timo Sirainen wrote:
> (Although many IMAP clients fetch 1:* flags after SELECT, but 
> even if IMAP server had no problems with that, the IMAP client 
> would probably be unusably slow so that's not a real problem.)

In Trojita, I always want to establish a fully synchronized view to a mailbox, which means either CONDSTORE or QRESYNC or a blind 1:* FLAGS fetch upon connecting to a mailbox, yes. At first, this looks like an ugly inefficiency, but I believe that it's more or less the only reasonable way.

A graphical MUA typically wants to show a simple statistic like X new, Y unread messages. I can get that number through the STATUS command, but what shall I do when receving EXPUNGE for a message whose flags are not known -- shall the number of the unread messages be decreased? Shall I invoke an explicit SEARCH NOT SEEN? Shall I just sync the flags in such case? (Note that  I cannot use STATUS on an already opened mailbox.)

It's true that one can probably come up with a pretty good heuristic like "on mailboxes >10k messages, it's unlikely to ever see expunges from the beginning, so let's load the flags only on demand" and defer to a full sync upon detecting a race. However, because there are extensions (CONDSTORE, QRESYNC) which make this synchronization painless and extremely efficient, I haven't decided to invest my time in optimizing Trojita for interaction with the legacy servers who don't implement these optimizations.

Some of these servers don't even support ESEARCH for an efficient compression of the UID ranges which are needed in any client wishing to maintain its own offline cache (for essentially the same reason -- you want to remove data from the cache upon seeing an EXPUNGE, but in order to do that, you have to know the UID of the message which was expunged or come up with creative ways of finding out that infromation on demand, which is far from trivial -- you could for example ask for the UID of just two messages, the one before the message being expunged and the second one right after it, but then you have to deal with network disconnects in some complicated way, and you would still have to solve this for expunges which have happened while offline, between your reconnects).

In short, yep, there are ample opportunities for clients to make the interoperability "better", but I somehow don't believe that clients should be responsible for this -- there are extensions designed to make this problem go away, and the two most widely deployed open source IMAP servers have implemented them for quite some time. It's a sad reality that many proprietary IMAP server vendors don't bother with ESEARCH, CONDSTORE and QRESYNC.

With kind regards,
Jan
_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol