Am Montag, den 08.01.2007, 22:22 +0000 schrieb robert burrell donkin: > > So I'm going to write a MailboxManager LocalDelivery and > > LocalSieveDelivery. > > could you explain just a little more about these?
There is nothing magic about it. :-) Current LocalDelivery accesses MailRepositories. If MailboxManager is used, LocalDelivery accesses MailboxManager through a MailRepository wrapper. A MailboxManager aware LocalDelivery will accesses Mailboxes directly. A LocalSieveDelivery can sort mail by a sieve script into different Mailboxes. > i've been trying to understand the design of MailboxManager for a > while now without success. If you have problems understanding the API, I'd be happy if you ask concrete questions. Many parts are just work-in-progress and I'm looking forward to suggestions. > 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. >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. :-) > i'm a little confused about why a general API > needs protocol specific methods. (i'm sure there are reasons but i > don't see them ATM.) Which methods are you talking about and how would you define them more protocol agnostic and still fulfilling all IMAP requirements? Yes many methods seem to be just taken out of the IMAP protocol. But in this stage that just means being pragmatic. I'm also a fan of having everything general, abstract, meta, aspect orientated, DI, semantic and foo. ;-) 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. > > i've been tying to think about email from a different perspective > > current solutions tend to be constrained by the central position of > mailboxes in their design. i think it's powerful to consider an email > as an URI: a identified resource. mailboxes are then just become > collections of resources but this seems really similar to other > searches. perhaps the inner workings of an advanced server need not > care whether the search is for mail in mailbox 'james', for mails from > '[email protected]' or tagged with 'james'. That's all nice and beautiful but the goal is a backend that plays well with an IMAP server. Unfortunately there are strong requirements, like uids, message numbers and events. You describe a vision. API, server and client are still to be written. I share many points of your critiques to IMAP as it is too complicated and limited in some points. But in reality it is the only wide standard to access hierarchical mailboxes from different clients for the next years. I'm sure James can be a platform for researching on next-generation mail API/client/backend and I hope for good ideas flowing in current James backend that is able to serve via IMAP. Joachim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
