Mark Crispin <[EMAIL PROTECTED]> writes: > On Tue, 11 Jun 2002, Simon Josefsson wrote: >> Still, my own use of UID SEARCH UID cannot be replaced by the above, >> since I need to know what happened to all relevant articles in the >> group before I create the window containing those articles. >> >> UID SEARCH UID is painful in large groups. A mechanism to better >> "synch" IMAP servers with IMAP clients with local caches or >> disconnected support would be useful, and is what I think is lacking >> in IMAP. > > Here's where being imaginative helps.
Every time I am imaginative with IMAP I encounter yet another server that is buggy, which makes users complain. Compare with your recommendation to compare the number of values returned in a UID SEARCH UID response with the number of articles in the mailbox -- coding all these "safety" checks into a client adds considerably amount of code. This is especially true if you want to interoperate against those buggy servers, since then you need to implement fallback workaround as well, when you trigger a "safety" check. I have implemented many safety checks and many workarounds for servers bugs, and whenever I do I always have the feeling that all this work is just because the IMAP protocol is too complex for its purpose. > From EXISTS, you know the size of window. You also know the highest UID > that you've ever got, so UID SEARCH UID <uidmax+1>:* will get you all the > new UIDs. > > You now know how many old UIDs there are. If that's the same as the > number of UIDs that you have, then no messages have disappeared. Nor can > any UIDs be added (remember that strict ascendency requirement). There is > no need to fetch the list of UIDs. > > Now, suppose some UIDs have vanished. Here is where some cleverness can > help you. Assume that in a very large mailbox, UIDs are more likely to > disappear at the ends then at the middle. So, using your knowledge of the > UIDs to generate suitable ranges, you can do partial fetches of the map at > each end, and stop when you find the hole. > > There. I've just outlined a technique that I could have patented if I had > not just put it into the public domain by documenting it here. How about > a "thank you, Mark, for such a neat idea."??? :-) :-) It is a neat idea, but if I would implement that I would still most likely have to keep my current behaviour as a fall back because there are buggy servers out there. To illustrate, the uidmax+1:* behaviour you rely on in the scheme was discussed recently, I think, and people had different interpretations. It is easy to state that the interpretation was wrong, but it won't make the problem go away and I'd still have to support various fallbacks.
