Geo Carncross wrote:
On Wed, 2005-03-30 at 22:21 +0200, Paul J Stevens wrote:
Geo Carncross wrote:
DBMail doesn't support IDLE [yet?]
I've added it to the TODO for 2.1.2 after reading the relevant rfc.
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?
One way to make it cheap is to have a global flag per mailbox/folder:
On login or logout, set the flag.
If a SEARCH command is run, clear the flag.
If the database is updated, set the flag.
If the SEARCH command (the EXACT SAME ONE) occurs again, AND the flag is
clear, return the exact same result-line.
Some clients try to use IDLE and handle it very wrong [most notably,
Outlook Express].
If you DO support IDLE directly, make sure that inactivity timers are
TURNED OFF during it, so really broken clients (Lookout!) aren't given
strange error messages.
Noted. Seems logical anyways to disable the inactivity timer during IDLE.
It's actually pretty easy: send random junk every 10 seconds (an empty
notification, perhaps) so that if a client disappears one of two things
will happen:
1. TCP output buffers will eventually fill.
2. We'll receive an RST from the remote.
Both cases are detectable.
Those are already detected quite well. We had a run of segfaults during the
2.0rc phase because STATUS response was sometimes incorrect and clients
disconnected by dropping the connection. All that was the reason for replacing
fprintf with a wrapper (ci_write) for detecting error conditions on the socket.
Outlook Express, btw, ignores the IDLE responses even though it
[sometimes?] appears to honor unsolicited updates.
Nice :-\
--
________________________________________________________________
Paul Stevens [EMAIL PROTECTED]
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands_______________________________________www.nfg.nl
