PHWinfo - Afficher un message - c-client & IDLE

09/04/2006, 21h16

On Sun, 9 Apr 2006, halayli@gmail.com wrote:
> Do you think it is a good idea for me to modify c-client and include
> IDLE message support since it will be a controlled environment? Because
> I had a look at the work you mentioned above, but I think it will take
> me time to implement it.

Given that you're going to sending notifications for multiple mailboxes,
you really want to use a real notification protocol. Otherwise, you will
be effectively implementing a private notification protocol on top of
IMAP.

Also, if you implement IDLE, you'll have to create some sort of coroutine
or other facility in c-client to make it operate asynchronously.
Currently, c-client is synchronous; a function call translates to sending
a protocol operation and then reading some set of protocol responses
ending with a response that terminates the protocol operation.

If you make the function that does IDLE return without waiting for the
response, then you need some mechanism in place when you do any other
operation to send the DONE and exit. You also need to have a thread
running to read the responses while IDLE.

If you make the function not return until the IDLE is done, then you avoid
the threading, but then your application isn't doing anything else unless
you have some sort of callback to a secondary event loop (albeit one that
returns rather than loops). You also need some sort of mechanism (perhaps
in the secondary event loop) to send the DONE. This is how I would do it
since it's much simpler than the other choices.

Otherwise, you have to make the protocol engine be complete asynchronous,
which would definitely entail multiple threads. That would be the best
way from a purely technical/architectural viewpoint, but it's also much
more work. And in the end, I don't think that it would gain much for all
the added complexity.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

09/04/2006, 21h16	#6
Mark Crispin Messages: n/a Hébergeur:	Re: c-client & IDLE On Sun, 9 Apr 2006, halayli@gmail.com wrote: > Do you think it is a good idea for me to modify c-client and include > IDLE message support since it will be a controlled environment? Because > I had a look at the work you mentioned above, but I think it will take > me time to implement it. Given that you're going to sending notifications for multiple mailboxes, you really want to use a real notification protocol. Otherwise, you will be effectively implementing a private notification protocol on top of IMAP. Also, if you implement IDLE, you'll have to create some sort of coroutine or other facility in c-client to make it operate asynchronously. Currently, c-client is synchronous; a function call translates to sending a protocol operation and then reading some set of protocol responses ending with a response that terminates the protocol operation. If you make the function that does IDLE return without waiting for the response, then you need some mechanism in place when you do any other operation to send the DONE and exit. You also need to have a thread running to read the responses while IDLE. If you make the function not return until the IDLE is done, then you avoid the threading, but then your application isn't doing anything else unless you have some sort of callback to a secondary event loop (albeit one that returns rather than loops). You also need some sort of mechanism (perhaps in the secondary event loop) to send the DONE. This is how I would do it since it's much simpler than the other choices. Otherwise, you have to make the protocol engine be complete asynchronous, which would definitely entail multiple threads. That would be the best way from a purely technical/architectural viewpoint, but it's also much more work. And in the end, I don't think that it would gain much for all the added complexity. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote.