Andreas Aardal Hanssen <[EMAIL PROTECTED]> writes:
> On Thu, 1 Aug 2002, Simon Josefsson wrote:
>>Andreas Aardal Hanssen <[EMAIL PROTECTED]> writes:
>>> On Thu, 1 Aug 2002, Simon Josefsson wrote:
>>>>a server where EXAMINE is faster than STATUS.
>>> Then don't select anything; just run status on all. And don't assume that
>>> the number you get is accurate, because it can never be (and it shouldn't
>>> matter to your application).
>>But my problem is I don't understand why I need to de-select the
>>current mailbox to invoke STATUS UIDNEXT on it.
>>Are you saying that to get UIDNEXT of the currently selected mailbox I
>>should close it and then invoke STATUS UIDNEXT?
>
> If your whole session is opened only to check the status of a bunch of
> mailboxes, then yes, do not select anything.
No, I use one network connection for everything.
> 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.
>>>>> It does work - it tells you the status of the mailbox at the time that you
>>>>> submitted the command.
>>>>The server complained that my client is buggy, so something is not
>>>>working properly.
>>> ...because you're issuing STATUS on a selected mailbox!!
>>So? Either the command works or it doesn't, you said it worked, but
>>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?
>>Re-reading 5.2 more carefully I see it only refers to using any
>>command to get the size of the mailbox. What exactly does "size of
>>the mailbox" refer to? I'd assume this means STATUS MESSAGES and not
>>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.
If I can't use STATUS UIDNEXT on the currently selected mailbox, the
solution I would lean towards is to unselect the current mailbox
(EXAMINE + CLOSE) and then invoke STATUS. This won't be slower than
SELECT+FETCH, and my clients' internal structures will have correct
information. The downside is that EXAMINE+CLOSE is slightly slower
than guessing 1+UIDMAX.
>>>>My original mail contained two problems though, the second one being
>>>>not able to select INBOX in that state. Any ideas on that one?
>>> You didn't close the first mailbox first, did you?
>>No, I didn't want to expunge the mailbox. SELECT + SELECT is legal.
>
> You pasted this into your original mail yourself, from 6.4:
>
> In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
> and the authenticated state commands (SELECT, EXAMINE, CREATE,
^^^^^^
> DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and
> APPEND), the following commands are valid in the selected state:
> CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID.
>
> Is SELECT allowed in selected state?
Yes.
