On 1/11/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Mittwoch, den 10.01.2007, 20:50 +0000 schrieb robert burrell donkin:
<snip>
> > 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.
And in fact it has to be done for many backends. If not, fine. Just do nothing on session opening.
most data stores (if i understand you correctly) have notions of state and session. i just think that the design would be cleaner and quicker if the different notions of session were separated.
What can be done stateful and what stateless depends on the backend and the implementation.
given appropriate design, it shouldn't do
If you take some operations and define them as stateless in the API, a backend implementation has no possibility to optimize any stateful thing.
just pass the state through to the backend in the call. the backend does not maintain the additional state but makes use of the data passed in.
If you define it inside a session, the implementation can just pass it through, without anything heavyweight.
the problem is that the session does not know about the protocol so it cannot decide whether it a heavyweight or lightweight implementation would be more appropriate.
> > It should keep the index as long as the pop3 session exists. > > The expunge of deleted messages should be done when the pop3 session > > closes. > > POP3 is not a stateless protocol > > the current generation of email protocols are broken. new protocols > are needed for the internet :-) Right, I'm talking about an API that performs well for SMTP, POP3 and IMAP. That is the goal. Future API for stateless protocols is a another discussion.
stateless protocols scale. others do not. good state management is crucial whether the protocol has conversational state or not.
> > Transactions mentioned by Stefano are also a point. > > what do transactions have to do with conversational state? Transactions are currently not part of the API. It is still to be researched what has to be attended when e.g. moving mails from spool to backend. But that's really another story. > the easiest way to kill performance is by long running transactions So the goal will be having short running smart transactions.
the API should help not hinder this goal - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
