On 1/22/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
> one of the tricky points about IMAP is that reasonable performance
> requires that commands be executed in parallel but there are complex
> rules that must be applied to the scheduling. to support concurrent
> access to the same mailbox by multiple clients requires understanding
> of all commands that all clients wish to scheduled against that
> mailbox. this suggests to me that the scheduler cannot be associated
> with a single handler.
This is interesting! Can you provide an example of how concurrency have
to be managed?
IMAP has two unique identifiers: message ID and UID. message ID is in
my personal list of the top 10 worst ideas ever included in a protocol
specification.
commands that rely on or change message ID must be serialized and
executed in the order that the client has sent them.
Does it mean we have to take care to correctly coordinate/sort commands
for different protocols?
i think so
for example, the SMPT server may add a new mail into the mailbox. IMHO
this should not be executed concurrently with IMAP commands that rely
on or change message ID.
Do you think it is better to manage sorting of commands instead of
simply using locks? Aren't locks enough for an IMAP implementation?
it can be done with locks but locks are inefficient
there are a number of IMAP commands that the specification implies are
fine to be run concurrently with an SMPT add operation. these should
not be blocked.
of course, this could be done by locking and i think that blocking
mailboxes will be necessary but IMHO scheduling offers better
performance, more flexibility and a cleaner architecture.
(forgive me but I don't have IMAP knowledge)
nothing to forgive: one of the reasons i've been pursuing this is that
i don't think anyone has a complete picture but we all have
information to bring to the table.
> given that a mailbox may (in james) may support multiple protocols, i
> cannot see clearly how this could be done without a single multiple
> protocol schedule per mailbox.
before IMAP we simply had MailRepository and MailRepository manage Locks
over Mail objects. MailRepository provide easy services and is
synchronized, everyone (pop3/smtp/spoolmanager/remotemanager) currently
uses the same repository interface.
i've been collecting usage statistics on my local IMAP server and IMHO
this kind of locking will ensure that james will never have reasonable
IMAP performance.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]