On 1/11/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Donnerstag, den 11.01.2007, 20:14 +0000 schrieb robert burrell
donkin:
> On 1/11/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
> > Am Donnerstag, den 11.01.2007, 18:55 +0000 schrieb robert burrell
> > donkin:
> >
> > > > > > Think of a mbox and pop3. The backend opens the file and indexes it.
> > > > >
> > > > > that is not conversational state but an optimization
> > > >
> > > > Right, but without a session there is no possibility for that
> > > > optimization.
> > >
> > > there are different ways which this could be implemented. the current
> > > session concept is not necessary and in some cases can be detrimental.
> > >
> > > a flaw with the current API is that a session is opened before the
> > > factory has any idea about what's it's to be asked to do. it is
> > > therefore inefficient to perform any optimization when the session is
> > > opened.
> > >
> > > for example, whenever an IMAP session is opened the session
> > > pre-emptively caches the UIDs. at this time, the session cannot know
> > > whether a particular command will need this information or not.
> >
> > As I said the last time: This is intended to be done on first use.
> > Just lazy initialization on demand. That way you need not know whether
> > it is needed or not.
>
> 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
messaging number is state that the current API forces to be associated
with the mailbox session since it's the only available option.
there are different approaches to the design of APIs and to state
management that i think may be worth considering. IMHO the system
would also benefit from another look at the layering.
interested?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
