On Thu, 2005-03-31 at 09:25 +0200, Paul J Stevens wrote:
> > Clients that support IDLE also [tend to] support unsolicited updates to
> > the current mailbox, which is just as good- and actually better if
> > SEARCH is cheap-enough.
>
> I'm not sure I understand what you mean by 'unsolicited updates'. Would that
> be
> like EXAMINE/SELECT or more like STATUS?
We could use those too...
>From RFC 2060, section 7:
Some status responses, and all server data, are untagged. An
untagged response is indicated by the token "*" instead of a tag.
Untagged status responses indicate server greeting, or server status
that does not indicate the completion of a command (for example, an
impending system shutdown alert). For historical reasons, untagged
server data responses are also called "unsolicited data", although
strictly speaking only unilateral server data is truly "unsolicited".
>From RFC 2060, section 2.2.2:
A client MUST be prepared to accept any server response at all times.
This includes server data that was not requested. Server data SHOULD
be recorded, so that the client can reference its recorded copy
rather than sending a command to the server to request the data. In
the case of certain server data, the data MUST be recorded.
{{ this is reiterated in section 7 }}
7.2.6. FLAGS Response
7.3.1. EXISTS Response
7.3.2. RECENT Response
7.4.1. EXPUNGE Response
These responses can come at any time and clients are REQUIRED to record
them.
7.4.2. FETCH Response
Contents: message data
The FETCH response returns data about a message to the client.
The data are pairs of data item names and their values in
parentheses. This response occurs as the result of a FETCH or
STORE command, as well as by unilateral server decision (e.g. flag
updates).
This means if a message becomes "anew", IDLE is better implemented as
simply sending out the updates unsolicited- or as RFC2060 calls them,
"unilateral server data".
Almost all responses (see RFC2060 for details) can come at any time and
most clients will do something useful with them [any that implement
command sending and response receiving separately; i.e. not StarOffice
IMAP and not UW's C-client... blargh]
If a client sent a SELECT/SEARCH operation for polling, they probaby
poll again soon anyway. We can send them the FETCH responses so they can
avoid a future FETCH. If clients see a EXISTS,RECENT,EXPUNGE change,
they can try their poll again sooner.
IDLE sets up a special "mode" where these things can happen EVEN THOUGH
no special mode was [ever] really needed.
I recommend avoiding IDLE because of the confusion that is caused by
certain clients that enter that IDLE mode. If that can't be done, be
very careful to disable timeouts as mentioned earlier.
--
Internet Connection High Quality Web Hosting
http://www.internetconnection.net/
