Am Mittwoch, den 10.01.2007, 20:50 +0000 schrieb robert burrell donkin: > > > > 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. > > > > The session orientation is not only for session orientated protocols. > > It's also needed for many backends. > > -1 > google REST :-)
What has it to do with accessing specific backends? I guess another good example are session orientated backends like JavaMail stores. If you want to access them stateless it becomes a mess. > > 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. And in fact it has to be done for many backends. If not, fine. Just do nothing on session opening. What can be done stateful and what stateless depends on the backend and the implementation. If you take some operations and define them as stateless in the API, a backend implementation has no possibility to optimize any stateful thing. If you define it inside a session, the implementation can just pass it through, without anything heavyweight. > > 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. > > 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. > > In fact sessions bring a bit inconvenience for the developer. But in the > > past stateless MailRepositories made problems. They were solved by > > putting it into a weak hash map. It's no good practice to let the GC > > decide about sessions. :-) > > IMHO one of the problems with the current API is a lack of clarity about state > > some state is conversational, other state is more naturally associated > with the actual mailbox and could be reasonably shared between > clients. What do you have in mind? IMO the implementation, that was written for a certain backend with a certain purpose, can decide perfectly how to handle this. > > That's like it is working now. The whole message number stuff is done > > inside a wrapper on top on a stateless backend class. > > the problem with using wrappers is that commands can't easily access > the lighter stateless layer Heavy and lighter depends on the implementation. If a wrapper just passes through, there is no reasonable cost. IMO it is important that the session implementation has the power to decide what to pass through and when to do any additional operations. > > > > It's really difficult to make the API general but still allow > > > > optimizations for a well performing IMAP server that is able to serve > > > > *many* clients. > > > > > > +1 > > > > > > it's hard to see the right way to factor the code but IMHO it's worth > > > making the effort > > > > That's my intention and again: I hope for some input on concrete issues. > > My last monologues about this topic always ended in some kind of a > > general discussion. Always some protocol agnostic / aware remarks... :-) > > but notice this time that it started from the general and is now > working towards the specific :-) Is it? Most of current discussion are universal phrases with outlook on future protocols, turning round in circles. Concrete is talking about method A in interface B. Or proposing completely modified interfaces to compare one against the other. > the inheritance hierarchy seems overly deep to me (both in the > interfaces and the implementation). perhaps this is a sign that the > API would benefit from additional layering. Can you elaborate additional layering? Joachim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
