On 1/10/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Dienstag, den 09.01.2007, 21:59 +0000 schrieb robert burrell donkin:
<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. The session orientation is not only for session orientated protocols. It's also needed for many backends.
-1 google REST :-)
Think of a mbox and pop3. The backend opens the file and indexes it.
that is not conversational state but an optimization
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 :-)
Transactions mentioned by Stefano are also a point.
what do transactions have to do with conversational state? the easiest way to kill performance is by long running 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.
> 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. > > IMAP as a protocol has some commands which are naturally stateful and > some which are more naturally stateless. superficially at least, it > seems more natural to me to think about a stateful session layering > above a lower level stateless API. 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
> > 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 :-) 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.
> message numbers are particular annoying :-/ > > but the fundamental needs of an email client should transend the protocol > > for example IIRC IMAP responds to events by writing to the socket. an > HTTP based email server may push RSS (say). the basic requirement is > similar. Unsolicited IMAP responses are only allowed after certain commands, not unilateral.
true (RSS doesn't really push anything either) - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
