On Fri, Jan 22, 2010 at 8:02 AM, Norman Maurer <[email protected]> wrote: > Hi Robert, > > comments inside..
true :-) > 2010/1/21 Robert Burrell Donkin <[email protected]>: >> On Thu, Jan 21, 2010 at 4:27 PM, Norman Maurer <[email protected]> wrote: <snip> >> here's the issues which spring to mind: >> >> 1. the POP3 protocol stuff is sound enough but MailRepository insists >> on instantiating heavy mail objects which kills performance for IMAP >> (my server died several times a day before i ripped out this feature) > > Thats true. I even don't think we need a Mail object at all for > serving email via POP3. Because we just need the "raw" email and > nothing more.. transforming via standard JavaMail (rather than Stefano's amazing workaround) alters the email so that SMTP->IMAP delivery is no longer specification compliant. i suspect the same goes for POP3. >> 2. the MailRepository allows actions which are incompatible with IMAP. >> (IMAP relies on the actual mail being read only with meta data >> including flags being read write.) >> >> 3. IMAP requires parsing supported by Mime4J which is incompatible >> with javax mail >> > > To be hornest, I don't like the whole javamail stuff to much. My > "vision" of new-geneneration james would be to not use javamail at > all. Javamail is just to "strict" of rfc validations etc and sucks in > terms of performance ( thats why we introduced all the wrappers to > lazy load stuff). +1 mime4j allows read only streaming partial pull parsing. most mailets just look at headers so this would be much more efficient and stop james dying when presented with a huge email. given mina, this would allow mail processing to begin before the mail is accepted and would allow unification between the micro mailets used by SMTP and mailets in the pipeline. >> 4. there are subtle semantic differences between the meanings of flags >> in POP3, SMTP and IMAP >> > > SMTP Flags ? You lost me here.. IMAP sets flags based on SMTP. JavaMail sets flags based on SMTP but not compatibly. IMAP-vs-POP3 eg POP3 delete has different semantics from IMAP's delete so separate flags are needed. (i suspect that most users wouldn't expect mail to disappear from IMAP just because a mail client has been configured with autodeletion.) >> 5. there are subtle differences in rules between a POP3 INBOX and an >> IMAP INBOX. not a problem to resolve but the code needs to understand >> whether it's been used for IMAP or POP3 so it can behaviour correctly. >> i think that this prevents the use of a single functional API. >> >> my thinking is along the lines of: > > True enough.. :-) >> 1. introducing a new messaging style interface specifically for mail delivery > > +1 maybe: deliver(String URL, Mail mail) would be a reasonable first step. (i agree that we need to revise Mail but i think that can wait.) URL gives more flexibility for virtual stuff and namespacing. for both IMAP and POP3 the storage of the read only raw data is logically independent from the read-write meta-data that's need to manage the mail. i suspect that the optimal performance would be to combine a flexible data store for the meta-data and file or http for the raw data. examples deliver("james://usern...@localhost/", mail) delivers the mail to account username deliver("jcr://username:[email protected]/general", mail) would be available to represent the delivery of a message to a JCR serving from bilbo.lan using a connection with user "username" and password "password" into the general space deliver("http://username:[email protected]/robert.donkin";, mail) and this would be available to represent the delivery of a message to a RESTful server (eg the blindingly fast CouchDB) at bilbo.lan using a connection with user "username" and password "password" POSTing to the robert.donkin URL. deliver("maildir:///rdonkin", mail) and this would be available to represent the delivery of a message into a mail directory on the local host with relative path rdonkin >> 2. introduce an efficient, simple, streaming POP3 backend API which >> can be adapted to MailRepository or other mailbox designs. performance >> for MailRepository would still suck but the OpenJPA (and potentially >> JCR) backends from IMAP could be used without heavy adaption or >> performance loss. > > +1 great :-) shall i take a look at this? >> 3. add full support for flags to IMAP. use custom flags to support >> POP3 mailboxing correctly. >> > > +1 i wonder whether we should ditch Flags from JavaMail and just roll our own >> so, we'd lose a general interface but gain interoperability between >> the protocols. >> >> - robert >> > > Sounds really good.. great - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
