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.
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.
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 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.
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.
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).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
