Robert Burrell Donkin ha scritto: > On Nov 2, 2007 12:54 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: >> Robert Burrell Donkin ha scritto: >>> the problem is that session is used in two different senses: database >>> session and a session of a (session-oriented) protocol >>> >>> if you're using a transactional datastore then yes, you'll need a >>> datastore session to execute transactions but there is no necessity >>> for this to equal the MailboxAPI session >> Maybe there are *3* different sessions: the protocol session (for POP3, >> IMAP, SMTP), the mailboxapi session, the datastore session. >> Or you are saying that the MailboxAPI session will be the same as (or 1 >> to 1 to) the protocols session? > > depends on the design. however, the MailboxAPI session is stored in > the IMAP session. this is necessary since the MailboxAPI session is > heavyweight (~1 second to create). for more protocols, creating a > session for a limited number of operations makes no sense.
I'm happy for this response because now it's much more clear that I misunderstood some your previous (old) messages. I was under the impression that you wanted to go stateless for every operation in API and I was worried about that "1 second" to be repeated for each operation because there was no more a real session concept in the API. >>>> Maybe the problem is that I don't know what the MailboxManager >>>> responsibility and API users are/will be so I don't know what layer of >>>> the architecture will be involved by this "API Design" thread. >>> i agree that this is the major problem: we need to understand the use >>> cases better >>> >>> - robert >> Maybe you are the one that better know both the implementations we >> currently have and the requirement for IMAP. > > Zsombor has made a start collecting requirements > http://wiki.apache.org/james/BackendMailboxAPI I don't see references about what I/O should be supported by the BackendMailboxAPI (BIO/NIO, SEDA/standard multithreaded). Had this been left out by purpose at the current level of analysis? >> Do you think we should evolve some of the currently existing api or do >> you think it's better to start from scratch a new design? > > people are already using the existing API so creating a new one from > scratch would probably be unpopular. but a review (and simplification) > is well overdue. > > - robert +1 Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
