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. >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."??? :-) :-) -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate.
