On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
<snip>
I try to restart from scratch and summarize. I think our main layers are 1) Protocol handling 2) Message processing 3) Message storage Most of the Joachim work is about the message storage.
IMHO no but at moment the implementation logic does not seem to reflect the layering above so it's hard for me to see clearly...
Most of the protocol handling code, imho, can be made common between our line based protocols (using the command pattern and maybe the memento for the session, like you propose).
depends on what you mean by most :-) IMO aiming for most (in terms of quantity) would be a mistake (lightweight frameworks and libraries are better). reusing patterns and aiming for the most important code to be sharable would be good goals. (i'm think from the other posts in this thread that there's reasonable consensus on this, just using different words.)
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. 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? (the storage API is also IMO broken but that's an topic best left until a another day) - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
