Andreas Aardal Hanssen <[EMAIL PROTECTED]> writes: >>> If you need to check the status while connected, then don't STATUS the >>> current mailbox, because EXISTS from select() tells you how many messages >>> there _were_ when you selected the mailbox, and "noop" will tell you how >>> 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. >>>>now you are saying it doesn't work because I used STATUS on a selected >>>>mailbox. If the latter is true, I think this should be documented. >>> It does work, it does the job, but the information you have from your >>> logged-in-session may be different from what STATUS gives you. And how can >>> you know which one to trust? The truth is - you trust what your session >>> tells you, and don't issue STATUS. >>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. >>>>UIDNEXT. So again I'm not sure I see any text forbiding the use >>>>STATUS UIDNEXT on the currently selected mailbox. >>> Size == number of messages. select 1234:* UID gives you the highest UID >>> number (last row). NOOP gives you "3 recent", and you add those numbers >>> 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. > > The fact is - the server gives you a state when you have selected a > mailbox. This state you can trust, as long as you update it with any > pending status updates. And I'm not talking about STATUS, but untagged > status responses. > > So if you're in a mailbox and the last you heard was that the highest UID > was 1234, and you haven't heard anything since then, then the only thing > you can know is that if new messages have arrived, then they will have a > higher UID. > > 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. 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 practically always by design (UIDNEXT = unix time). A SELECT+FETCH operation is time consuming enough so that I don't want to risk wasting it if I can get by cheaper. Do you see why I want the "real" UIDNEXT value now? 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 interprete UIDNEXT to be. 3.1.1 of RFC 2683 is more serious though, 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 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.
