On 1/13/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Samstag, den 13.01.2007, 10:53 +0000 schrieb robert burrell donkin:
> > > this is a good example of why i claim that state needs to considered
> > > more carefully. hopefully it may also illustrate why i claim that
> > > session is harmful.
> >
> > That's not fair. :-( It's just an example for work-in-progress. I
> > explained that I removed the lazy init because there was a problem I
> > hadn't time to investigate further on.
>
> didn't intend this to be a criticism of you personally - i understand
> how difficult IMAP is and think you've been doing a great job :-)
> i shouldn't have rushed to specifics so quickly since i'm trying to
> criticize the API rather than the implementation
>
> but it is a good illustration of the kinds of problems that the
> current API creates
No, I don't agree. You can not judge missing optimization of a prototype
implementation as weak points of the API.
the API fails to pass sufficient information to the backend to allow
optimization. this is an architectural flaw. yes, a good
implementation will find a work around but the price is messy code.
And please note that concrete proposals and suggestions for improvements
have much more value than critique and abstract discussion.
Critique is just more welcome when it comes with a concrete solution
like a patch. :-)
going to the trouble of locally ripping out and replacing the current
APIs seems like a waste of time to me and seems likely just to cause
heated debates in the future. i can sketch a solution, though.
the current APIs are a classic example of an API which has grown over
the years without design. they tend to become crufty as every new
optimization or function requires more methods to be added. each extra
call breaks backward compatibility so it's not really possible to have
more than one implementation.
move to a cleaner, simpler interface. the command pattern is a nature
fit. let the commands handle the parsing and the backend the data
processing.
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)
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
