Am Dienstag, den 09.01.2007, 21:59 +0000 schrieb robert burrell donkin: > AFAIK SIEVE scripts conceptually operate once mail has been delivered > to a user. how do you see the configuration working?
The LocalDeliver Mailet is the point in the chain where the Mail gets just delivered. In fact it is responsible for actually storing the mail. A SieveDelivery Mailet would look for a sieve script for the local recipients and perform it, if it is existing, otherwise store the mail in INBOX. > > > there are various methods to get various > > > flavours of session. > > > > Currently there are three. > > The problem is that IMAP has many requirements to a backend. Many > > backends successfully used for POP3 will probably never fulfill them. > > perhaps it depends on the abstractness of the perspective: i suspect > that it all reduces to storing the email content and meta-data about > the email, at least for the storage. Storing is only one method + one convenient method with less parameters. > > 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. Think of a mbox and pop3. The backend opens the file and indexes it. 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. Transactions mentioned by Stefano are also a point. 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. :-) > 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. > > 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... :-) > 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. There is an IDLE extension to the protocol but I'm not sure who implements that. Joachim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
