Geo Carncross wrote:
On Thu, 2005-03-31 at 09:25 +0200, Paul J Stevens wrote:
I'm not sure I understand what you mean by 'unsolicited updates'. Would that be
like EXAMINE/SELECT or more like STATUS?
[..]
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
[..]
Let me see if I get this straight.
We could change the blocking fread on the client stream to a non-blocking select
based version while making sure we can safely interrupt anything we happen to be
doing while waiting for commands from the client. This will give us plenty of
idle time on our hands to use for stuff like sending unsollicited responses and
possibly idle output.
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.
Interesting stuff. By using select on the command channel we can provide
unilateral server data, one special case of which is IDLE data.
Still have to absorb the self-pipe pattern though. I havent found a good example
yet, and djbs description reads like a zen koan.
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
