Re: [IMAP] APPEND Command Usage

Quoting Stuart Brandt <[email protected]>:

> On 12/18/14 2:22 PM, Michael M Slusarz wrote:
>
>> I would imagine the most common behavior is that a client would grab the
>> append limit before it's first append, and it is less expensive to issue
>> "STATUS mailbox (APPENDLIMIT)" than a LIST command with APPENDLIMIT
>> return in that situation since the status info is all that is needed.
>
> My preference for the LIST-STATUS case over STATUS case comes from  
> the following statement in section 6.3.10 of RFC3501:
>
>       Unlike the LIST command, the STATUS command is not guaranteed to
>       be fast in its response.  Under certain circumstances, it can be
>       quite slow.  In some implementations, the server is obliged to
>       open the mailbox read-only internally to obtain certain status
>       information.  Also unlike the LIST command, the STATUS command
>       does not accept wildcards.

I believe this references calculation of data like unseen and total  
message counts, where you potentially need to parse the mail store to  
determine the information.  APPENDLIMIT will almost certainly be a  
static configuration value that doesn't depend on the actual mailbox  
contents so performance concerns should be negligible.

LIST-STATUS suffers from the same concerns as the 3501 text: backend  
status calculations do not magically get any faster piped through  
LIST-STATUS rather than a STATUS.  LIST-STATUS brings advantages in  
that you can get status information from a list of mailboxes, or from  
a list of mailboxes that you do not yet know, and you save on having  
to deal with the pipelining of multiple mailboxes yourself which  
potentially allows a server to optimize the lookups, but it isn't any  
faster in returning the results from a single mailbox as far as I know.

michael


___________________________________
Michael Slusarz [[email protected]]

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext