robert burrell donkin wrote:
Initially I thought this thread was about 3, while your diagrams seems
to me about 1: this is why I'm confused.
the diagram concerns the interface between the handler and processor
layers (as defined above)
i think that i now understand the reason for this confusion: the role
of the mailbox API is conceptually blurred between the processor and
storage layers. i think that the biggest single improvement that could
be made to the API would be to clearly separate these layers.
we need an object in the processor layer which understands how to
manage concurrency between protocols and users. james will not achieve
adequate IMAP performance until commands can be scheduled for
concurrent execution.
Shouldn't the storage layer already provide a solid way to access and
manage the content?
I thought that once I have an API to read/lock/write/alter/move messages
in the storage I should not care about who else try to access the same
storage concurrently to me, I should simply be able to do what I need
and being blocked (synchronously or asynchronously) if someone else have
priorities over me (it is currently locked).
for the handler-processor interface, it seems to me that this probably
requires that:
* all conversational state be held in the handler layer
* movement to a messaging style API capable of being schedule using SEDA
* one mailbox processor object per mailbox
* no direct access to the storage layer
am i making more sense now?
1) ok
2) The SEDA stuff is what we prepared in the handlerapi-experiment.
TO make it simple you have a command object for each protocol command
and this command receive the current session as a parameter of its
processing. "Session.write()" is intended to become asynchronous when
we'll move to MINA, but it is not so important now (the call does not
change).
3) I don't know what a "mailbox processor object" is and I don't know
what is a "mailbox" in this context. Is it like the javamail "folder" (a
list of messages + properties) or is it already a hierarchy of folders?
4) Do you mean that once the handler created the specific command and
invoke its method passing the current session it should use the previous
"mailbox processor object" to access the storage layer and not have
access to the storage layer ?
(the storage API is also IMO broken but that's an topic best left
until a another day)
Maybe I would understand it better if we start from the lower level that
I can understand better given my lacks about IMAP.
Please note that I don't want to "waste your time", so if you think you
already have good knowledge of what james *is* currently and what have
to be done maybe you don't need my replies/opinions and the best way is
to simply start a branch and do what you think have to be done. This way
we can oversight concrete changes and I'm sure I can understand code
much better than words.
- robert
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
