Re: [Imap-protocol] Re: Courier bug(?)

Quoting Dave Cridland <[email protected]>:

> On 28 Jan 2013 22:00, "Michael M Slusarz" <[email protected]> wrote:
>> IMHO, a more sensible approach for a disconnected client, rather than
> trying to keep a sequence->UID map (ugh)
>
> No, really, this is a sensible thing to be doing for a number of reasons.
>
> Firstly, it'll help if you don't get a UID, and secondly there's all sorts
> of interesting tricks you can do if you know the UID/seq mapping.

I'm sure that some clients see some benefit from these tricks, but  
that certainly doesn't mean that all clients will.

> Not least QRESYNC more or less requires you to, if you want it to be
> efficient in telling you what's been expunged.

In practical usage, this is not true.  We actually wrote all the code  
to handle seq/UID mappings and use this information to populate the  
4th argument to QRESYNC.  And we discovered it was all a giant waste  
of time.  The effort in maintaining the mapping and producing the 4th  
argument every time a mailbox was opened *far* outweighed any benefit  
from obtaining more compact VANISHED responses.  Mainly because any  
user only has at most several hundred cached entries in any given  
mailbox (even if that mailbox contains hundreds of thousands of  
messages).  So that code was ripped out almost immediately.

With connected clients it might make sense since they have a full (or  
mostly full) copy of the mailbox in the local cache.  But with a  
disconnected client and/or a client that implements a view/window  
based interface to a mailbox, the number of cached entries will be  
much closer to the size of the window rather than the size of the  
mailbox (,as the mailbox size increases).  YMMV.

>> Only if these 3 items occur does a client need some other way of linking
> the flag changes with an UID.  Since this event should occur only extremely
> rarely, if at all, one appropriate way of correctly syncing the local cache
> would be to:
>>
>> 1. Ignore the returned FETCH information for local caching purposes.
>> 2. Immediately reopen the mailbox.  (The client's existing
> CONDSTORE/QRESYNC will ensure that the mailbox is correctly sync'd).
>
> Yikes.
>
> Well, that'll work, of course, but it's pretty inefficient.

The inefficiency of this code is irrelevant since it is *NEVER* run.   
I've yet to see a real-world example of an existing CONDSTORE/QRESYNC  
server that even triggers this code.  So the code is there to ensure  
the spec is followed, but the optimization is to real-world usage, not  
the black letter of the RFC.

michael

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