On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
> i've taken the liberty to create:
> http://svn.apache.org/repos/asf/james/server/sandbox/design-doodles to
> house speculations such as this.
>
> i've added something very basic to
>
http://svn.apache.org/repos/asf/james/server/sandbox/design-doodles/imap/messaging-api/.
>
> it was useful for me since i needed to think a little more about the
> design: since james supports hetrogeneous mailboxes, the
> conversational session will need to be created by the handler and then
> stored for each mailbox.
>
> shout if it's still unclear and i'll try to do better :-)
>
> - robert
I think this is a step back from the current design or it simply regards
something we already trying to solve differently with the handlerapi.
the current API design is flawed: this is just one way to fix it.
but yes, i'm heading towards patterns which allow more efficient
parallization of processing
I think that a command pattern having an ImapCommand as the command
cannot be the api to the backend (the MailboxManager). The
MailboxManager shoudl be able to provide results for Imap, for POP3, and
for other protocols we may want to provide.
then it's already a failure :-)
mailbox is coupled to IMAP and the more you optimize, the tighter than
coupling will become
from an outsider's perspective, given you've already opted for that
approach, the question is simple how best to organize that coupling.
the way you've chosen prevents anyone maintaining independent
implementations.
About the command pattern applied to our services we are already working
on a common infrastructure to reuse part of our network layer between
services and prepare for asynchronous handling: you can look at the
smtphandler in james 2.3 for the first implementation, you can look at
the handlerapi-experiment for a more advanced solution we're working on
as an experiment.
the best plan would be to use SEDA
this requires use of messaging APIs
from what i can tell from looking at the newer code, you seem to be
moving towards a messaging API but the interfaces suffer from the
usual faults (too complex, probably unmaintainable going forward).
maybe you'll get there in an iteration or two.
The plan for the line based plaintext protocol layer infrastructure was
to complete the handlerapi-experiment and start a proposal: after this
we will decide wether to use the new handlerapi or not, and wether to
port our current protocols (Imap too) to the new pattern.
That said, I think that a Mailbox should not be aware of ImapCommands:
this make the storage layer directly aware of the protocol layer.
the mailbox is aware of the protocol already: the only question is the
nature of the coupling
ATM you have an inefficient call based API. over time, optimizing this
will ensure that the backend become very tightly coupled to the
demands of the protocol. this has already happened. for example, a
separate backend implementation is required to efficiently support
stateless protocols.
of course, anyone who tries to build alternative mailbox
implementations outside the james core team is going to be out of
luck. every release will need to break those core interfaces to allow
more optimization.
I think the part of code that need specific factoring and discussion is
the inside of the box you named "ImapMailbox": how do you retrieve
messages, how do you delete them, how does it handle transactions, how
do you search for messages, how do you move messages between multiple
mailboxes and so on.
but that's the point: admit the coupled and push the work into the
mailbox. most IMAP implementations will layer top of more general
backends but it will also be possible to create implementations with
completely independent implementations.
If you are interested instead on something more protocol oriented please
join us on the handlerapi-experiment (look at the smtpserver, that is
our current guinea-pig for this work).
i'm not interested in heading again down a road that's bound to end in
tears. if i decide that james is too slow for me to live with any
longer, i'll probably just hack my local fork.
i'm interested in having a IMAP implementation that i don't have to go
and make a cup of tea when i'm opening my mailbox. i'd also like an
implementation that could handle my full mailbox not just the 5-10%
that i'm forced to load into it ATM.
i am disappointed that you let me waste time (that i could have spent
more valuable elsewhere at apache) outlining designs that you were
never going to accept. next time please be clear up front. that way, i
wouldn't have to pull jochen's implementation apart ;-)
but thanks for taking the time now to let me know that you have your
new design and you're not interested in alternatives
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]