Sam Varshavchik wrote: > Robert J. Cups writes: > >> I realize that if I had X EXISTS cached somewhere I could do a fetch >> with that, but I didn't have convenient access to that value and >> capturing it would require additional processing, the overhead of which >> I wished to avoid. > > > All IMAP clients must keep track of the number of messages in the > mailbox, if they want to perform any kind of a useful task. This is > one of the basic IMAP tenets. > >> I am aware that I could request STATUS <mailboxname> (UIDNEXT), but this >> is not guaranteed to be fast. Courier also does not seem to send an >> untagged UIDNEXT on SELECT either. >> >> If you have any suggestions on a better way to get the highest (or next >> highest) UID that is reasonably efficient on Courier as well as the >> other major IMAP servers, I would be all ears. I'm not trying to split >> hairs, I'm honestly trying to accomplish something. > > > First of all, if the highest existing UID is 5, you cannot assume that > the next message you see will have UID of 6. Nope, nope. If you > thought so, think again. > > For starters, by the time you get around to checking for new messages, > another message could've been added to the mailbox, got a UID of 6, > then someone else deleted and expunged it, so the next message you get > will have a UID of 7. > > Yes, that means that UIDNEXT is completely and utterly meaningless as > well, for precisely the same exact reasons. If you rely on what > UIDNEXT tells you, you're going to have a spectacular blowup the next > time someone manages to sneak in and quickly delete a message, under > your nose. UIDNEXT is fundamentally broken. It is completely > meaningles. Well, it's there, but only because it's supposed to be > there. > > The closest thing to what you want is: > > <tag> FETCH * UID > > should get you the UID of the last message in a nonempty mailbox. For > empty mailboxes you may get an error, or no results, depending on the > server. > > But I still think that whatever you're trying to do, your approach is > not the right one. I wrote an fully-functional IMAP client. It does > everything with an IMAP client that any IMAP client might want to do, > including IDLE, and the whole jazz, while side-stepping all that's > broken with IMAP. And I never needed to twist myself into such a > pretzel, not even close. > > As an IMAP client, if you do it right you will always know exactly > what's in the folder. You get the message count when you SELECT it, > and by paying attention to EXISTS, FLAGS, and EXPUNGED messages you > know exactly what's in it, at any time. When you initially SELECT the > mailbox you do, sadly, need to do a "FETCH 1:* UID FLAGS", to capture > the mailbox's state (which I think is a design flaw), but from that > point on you're in the driver's seat and you will always know exactly > what's in there, simply by paying attention to three messages when you > receive them. > I'm writing a proxy, not a client, so it is entirely possible for me to do useful things without keeping track of the number of messages in the mailbox :-)
Also, I'm aware that the next UID may not be 6, but if the UID is >= NEXTUID, I know that it is new [to me]. (For various reasons, I need to know if it's new as in "I've never seen this before", not just \Recent, and I don't want to do anything that would clear the \Recent flag from the client's perspective). What I'm writing is something like a filtering proxy, so if one slips in under the radar it's not end of the world, just mildly annoying. I think that FETCH * UID is exactly what I want, and thank you for the suggestion. Trying to maintain anything more than the minimally reasonably sufficient state for potentially large numbers of simultaneous connections is not really worth it to me when weighed against the small effect of possibility of potentially not filtering a message that slips in. I understand your point that from a client's perspective, UIDNEXT is not that useful, but for my use it's sufficient given my relaxed requirements. Thanks for taking the time out to share this information and help me out - I appreciate it, and apologize if I touched on any sensitive subjects. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Courier-imap mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
