[prev in list] [next in list] [prev in thread] [next in thread] 

List:       imap
Subject:    Re: SUB/LSUB usage for mail
From:       Mark Crispin <MRC () CAC ! Washington ! EDU>
Date:       2000-08-14 18:52:43
[Download RAW message or body]

On Mon, 14 Aug 2000 14:38:48 -0400, Cyrus Daboo wrote:
> As I recall, I believe
> the new responses could also include the equivalent of the status response
> data.

It would be an ill-advised idea for a client to rely upon such a thing.

The reason why STATUS does not take wildcards is that it is not necessarily
cheap to obtain that data.  It's bad enough with clients doing LIST * without
them doing the equivalent of STATUS *.

What this means is that you need to have some intelligence in the client, and
planning on the part of the user.  Most users only have a few incoming
mailboxes, but may have hundreds of secondary mailboxes (new mail is never
delivered to these, just copied by user operation).  Use of the subscription
mechanism, and/or mailbox organization (e.g. all incoming mailboxes are
located in incoming/*) is an example of this.

Speaking from an architectural point of view:

It's important to recognize that IMAP is *NOT* a means of shoving difficult
client problems onto a server.  IMAP is a means of implementing distributed
mail.  The client and the server have to act in partnership.  The performance
implication is that each side has to consider the requirements of the other.

>From inception, IMAP contains certain assumptions about server performance,
e.g. that the "FAST" fetch items (flags, internaldate, and exact RFC822 size)
are instantly available, or that a server is obliged to perform even the most
complex and expensive searches.  These assumptions have historically been
quite problematic for some server implementations; note the ongoing problem of
servers not returning good RFC822.SIZE values.

We should eschew adding assumptions of this nature unnecessarily.  Potential
new facilities need to be examined carefully with regard to impact on both
client and server.

[prev in list] [next in list] [prev in thread] [next in thread]