On Thu, 1 Aug 2002, Simon Josefsson wrote: >Andreas Aardal Hanssen <[EMAIL PROTECTED]> writes: >>>> many arrived since then, and it will also often give you a new EXISTS. >>>Which doesn't give me the UIDNEXT. >> Yes it does. >How? 1+UIDMAX doesn't equal UIDNEXT.
It equals the number-which-is-one-more-than-the-current-highest-UID. What exactly is UIDNEXT, if not this? >>>The session doesn't tell me UIDNEXT. >>>Should I trust a guess that UIDNEXT = 1+UIDMAX instead of what STATUS >>>UIDNEXT is telling me? >> Yes! For all you can use UIDNEXT for. >You are forgetting that I can use two UIDNEXT values to compare them >for equality. If I guess one of the UIDNEXT values, inequality >doesn't necesserily mean there is new mail and then I waste time >finding out. Yes, and since NOOP gives you exactly the same for the mailbox you have just selected, you don't need UIDNEXT from STATUS. You know everything you need by issuing NOOP. >>>> together. >>>Which isn't guaranteed to be correct, and when it is incorrect it >>>causes an unnecessary SELECT+FETCH on that mailbox. >> Ah, here's the problem. >> You seem to think that a UIDNEXT will ever be correct. How do you define >> "correct", considering that emails can arrive, get deleted, and so on and >> so forth continuously all the time? UIDNEXT is wrong the moment after a >> message arrives - and you can never know when that will happen. >> STATUS gives you a snapshot, in a select, untagged status responses give >> you current state. Unless you lock the whole depository some way, you can >> never know what UIDNEXT is. >I don't rely on UIDNEXT being the "correct" UID assigned to the next >article, I only rely on it being monotonously increased whenever there >is new mail. Yes, and NOOP will say "3 recent", which is even more exactly what you want. You're trying to find whether or not there are new mails, and NOOP tells you *exactly* this. >What I do is this: Sample UIDNEXT at time X and store it. Then at >time X+1 I sample UIDNEXT again, and compare the two values. If they >differ I do SELECT+FETCH 1,* UID on the mailbox, to find out the >highest/lowest article number which I need. If I guess one of the >UIDNEXT values as 1+UIDMAX, I may waste a SELECT+FETCH operation which >is time consuming. In fact, the operation will be wasted whenever the >guess 1+UIDMAX = UIDNEXT is wrong, which on some servers is >Do you see why I want the "real" UIDNEXT value now? If you do a NOOP, it will tell you how many new messages are in your currently selected mailbox. The FETCH 1:* UID will then give you the UIDs of whatever is *now* in your mailbox. This is no different from using STATUS, other than that STATUS doesn't relate to your selected mailbox'es state. Btw, don't do FETCH 1:* UID unless you need all the former ones. First use the EXISTS number you got from SELECT, then add all the new messages that you gain knowledge from with NOOP, then fetch MAXNR:* UID. >Alternative schemes to achieve the same thing would be appreciated, of >course. >I still think STATUS UIDNEXT on the currently selected mailbox should >work. �5.2 in RFC2060 refers to message size, which I don't *mailbox size*, not message size. >interprete UIDNEXT to be. 3.1.1 of RFC 2683 is more serious though, mailbox size is "number of messages". Which is exactly what you're using UIDNEXT for. You're trying to see whether or not the mailbox has got new messages in it. Using STATUS to get this info from the currently selected mailbox is silly, because you already know what you need. >but if I follow its recommendation, the only alternative is to do >EXAMINE x+CLOSE+STATUS x UIDNEXT. I will implement that as a fallback (please..) EXAMINE one mailbox, then STATUS on all other mailboxes. The one you are in, just NOOP. If you don't know how to interpret the response from SELECT + untagged status response, then please say so! >if the STATUS command returns a tagged BAD response. Returning an >untagged NO response as the server in this thread calling the client >buggy is simply wrong. Either the server should succeed the command >properly or it should refuse to perform the operation due internal >server limitations and return BAD. The server is just saying that what you are doing is silly! ;)) BTW, untagged NO is usually fine as a warning to the client. Andy -- Andreas Aardal Hanssen
