On 1/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
<snip>
>> From the other side developers maybe just don't need a full featured >> ImapSession for their needs and want to use an easier interface. >> >> That was the intention for providing different "flavors" of sessions. >> MailboxSession easy to ImapMailboxSession advanced. >> >> At the moment I'm not even sure if there should be different interfaces >> and if they should be in one hierarchy or separated... It's all >> possible. :-) > > ATM the API is very session oriented. to access email means opening a > session with state preserved between invocations. i can appreciate > that with stateful protocols, it's going to be necessary to have > really pretty different session objects. > > but i wonder whether it might be possible to factor the code so that > these stateful sessions are layered on top of more stateless > operations. Currently James does not support transactions for the spooling/storage: I think that planning a refactoring we should think to support transactions. If I'm not wrong there is no way to achieve transaction support without some sort of session support.
i suppose that depends on what you mean by a session :-) perhaps you mean by session what i would call an atomic operation one natural concept of session is as the state retained on the server recording information about an ongoing conversation which may be needed in the future. for example, a http session tracks the same logical conversation. this concept is the one i meant the more i stare at the API, the more i wonder whether it isn't much more natural to build a stateful API upon REST. it seems more natural to me for the protocol implementation to pass the session (in the conversational sense) through to the API. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
