On 1/22/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
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).
(apologies to stefano for replying to this out of sequence: i think we
have a better mutual understanding now but this gives me a good start
place to help me develop some ideas)
the storage should only concern itself with it's internal needs for
concurrency management. this is necessary but not sufficient. there is
also a need to manage concurrent access from protocols and users which
is storage independent.
> 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?
<snip>
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?
'mailbox' concept already appears in the james. i'm little hazy about
it's intended purpose but i would like to think of it as a collection
of messages with meta-data (but then i would say that, wouldn't i ;-)
'mailbox processor object' emphasis that it's concerned to processing
protocol operations rather than storage
i think james need to separate more clearly processing from storage
but that the mailbox (in the collection of mail plus meta-data)
concept may well be represented in both processing and storage layers.
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 ?
yes
this would allow the competing scheduling demands of different
protocols and users to be resolved above the storage layer
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
