I have some questions about $subject, motivated by a desire to reduce
unnecessary client<->server traffic due to living on the wrong end of a
64K ISDN line, and watching the IMAP traffic in a debugging session of
Evolution.
1. The 'IDLE' extension (RFC2177) looks at first glance like a sensible
thing to do, but on closer inspection it doesn't really help much.
Consider the case where the following happens, in this order:
1. Client SELECTs a mailbox.
2. Mail arrives.
3. Client issues 'IDLE' command.
AFAICT nothing in RFC2177 states that the server 'MUST' immediately
inform the client of changes to the mailbox which have occurred since
the mailbox was selected, and unless that behaviour is required, there's
_always_ a race condition between selecting the folder and entering
'idle' mode.
Is there any way a client can _safely_ use the IDLE extension and rely
on actually being informed of _all_ updates? Do all current
implementations actually fix the race condition above? Testing with
Courier shows that it does seem to notify me of mail which arrived
within the window described, but it's not clear that a client could rely
on that.
2. The other problem with the IDLE extension is that it only affects the
one currently-selected folder. Is there any work on, or discussion of,
an extension similar in spirit to 'IDLE' but which also permits the
selection of multiple folders for asynchronous status updates. It's
common for an IMAP client to be checking for mail in _all_ folders (or
all subscribed folders), but this is still only possible via polling.
3. On a related note -- is it permissible for a client to rely on the
\Unmarked flag to optimise away a STATUS command for certain folders
when polling for new mail? I suspect not -- it seems to me that it's
permitted for a server to show a folder as \Unmarked if _another_ client
has selected that folder since the new mail arrived, hence that a client
must issue STATUS for _all_ folders in which new mail might have
arrived, regardless of their Marked/Unmarked status.
4. What mechanisms exist or have been discussed to allow client-side
caching of message flags (such as \Seen, \Answered in particular). I
observe that Evolution downloads flags for _all_ messages in a folder
the first time a folder is selected after startup. If flags are changed
by another client, Evolution won't notice until it's restarted. Looking
through the RFCs, I see no option for a client other than to re-fetch
all message flags _every_ time they're required; no mechanism exists for
a client to be able to know that flags _might_ have changed. Hence
Evolution is technically at fault for doing any form of caching of flags
at all.
Would it be feasible to add something like a flags-sequence-number which
is incremented each time flags for existing messages are changed, which
a client can use to invalidate its cache of message flags?
--
dwmw2
--
-----------------------------------------------------------------
For information about this mailing list, and its archives, see:
http://www.washington.edu/imap/imap-list.html
-----------------------------------------------------------------
