On 1/13/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
> manage the state more clearly. allow the backend access to more
> information about the conversational state. the parsing layer should
> manage the conversational state but this should be done through an
> interface. the implementation should be provided by the backend
> allowing additional information to be associated.
>
> the whole IMAP API interface would be something like:
>
> public IMAPConversationalSession createIMAPSession()
> public void execute(IMAPConversationalSession state, IMAPCommand command)
Robert, I'm not sure I understand you.
Are you proposing an IMAP API composed by 2 methods? A command pattern
applied to a session? Do you call it an API?
i most definitely call it an API :-)
one of the messaging style
I think that this is too abstract and I feel I'm not understanding what
you propose.
If I understand you simply want to change the current pattern:
public IMAPConversationalSession createIMAPSession()
public void IMAPConversationalSession.execute(IMAPCommand command)
So simply have the session as a parameter for an executor instead of
using it as the executor.
the concept of what a session is changed too: it's conversational session
If I understood you you simply propose to add
a Memento pattern to the Command pattern.
yep - i never claimed to be original
Imho this is a small change
and can be changed with small refactorings, but I don't see HOW this
changes the complexity of the API.
it's small but subtle
it changes the conceptual relationships between the layers
the IMAP server manages conversational state, parses input and formats output
the intermediary layer processes the commands and interacts with the
data store. this ensure that all information that is know is available
to the implementation.
the interface to the data store at this layer may well become a more
usual call-centric API but it's pushed to a lower level in the API
structure and allows both radically different implementations, and
implementations that provide specific optimizations targeting backends
known to allow them.
> yes, i know that this pushes some of the problems into the backend but
> i think that these could be solved by layering below the mailbox
>
> - robert
If you can provide some sort of code to explain your ideas I would be
really happy.
Feel free to create a sandbox and provide a strawman implementation of
what you mean or to refactor the real code (much better to understand).
If you feel more confortable with diagrams I'm happy with them too, but
I need something more concrete to continue this discussion.
if there's interest, maybe i'll pull together some UML
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
