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

List:       imap
Subject:    Re: Asynchronous 'hints' to the client to reduce polling
From:       Mark Crispin <MRC () Panda ! COM>
Date:       1997-02-17 22:31:55
[Download RAW message or body]

OK, you seem to be on the right track.

I'm not sure that it's necessary to have the requirement that IDLE return a
tagged OK after an EXISTS, EXPUNGE, etc. event.  Suppose that IDLE is required
to return the tagged OK only after the client issues a command, and that other
events are permitted in this state.

This would then make the definition of IDLE be a declaration from the client
that it is prepared to accept data from the server, and that since it is
asynchronously listening the server doesn't have to worry about deadlocks.

The main difference is that the client has the choice of whether or not to
terminate the IDLE by its (in)action, rather than having to renew the IDLE by
action.

One interesting side effect of IDLE is that it makes it possible for the base
spec to forbid server responses when no command is in progress, since IDLE now
supercedes this function.  No more stuff about the communication windows and
flow control considerations that many people have trouble understanding;
synchronous software is protected from deadlocks and asynchronous software can
do its thing.

I don't think that we can introduce IDLE into the base spec without resetting
the clock.  But I think that the base spec can be altered to forbid server
responses with no command in progress, with the knowledge that the IDLE spec
takes care of this.

It's an interesting possibility.

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