Serge Knystautas wrote:
On 1/23/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Can you make a common case example where the need of multiple concurrent
processors is needed for a single client? (if I have a concrete case I
remember better the issue in later discussions)
- You have 2 emails in your inbox. You move email #1 to another
folder and go to download email #2. The move action could well
complete after the download (next message) action.
More exagerated cases..
- search action begins sending message headers, and you click one of
the first messages before the search has completed.
- sitting waiting for 100 messages to be moved from one folder to
another and do an idle check to see if new messages have arrived.
I would suggest looking briefly at the raw IMAP protocol. It makes
the protocol nasty, but every command gets a unique token so that
requests and responses are asynchronous. I would presume this is why
someone like Andy will question the larger scalability of the protocol
given its complexity and how the asynchronous nature of rich email is
built right into the protocol instead of having the client create
multiple HTTP connections in a REST style.
Thank you very much!
My bad, I knew that commands took an unique identifier in IMAP but I
always thought they was managed sequentially and not concurrently.
Reading the IMAP spec a bunch of time in past I always noticed the
response was anynchronous, but I never "recorded" they also could have
been concurrent. I thought it was only something similar to ESMTP
pipelining, instead I now better understand Robert concerns.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
