Hi Robert, comments inside..
2010/1/21 Robert Burrell Donkin <[email protected]>: > On Thu, Jan 21, 2010 at 4:27 PM, Norman Maurer <[email protected]> wrote: >> Sure, I would be very interested in discuss stuff. > > cool > >> I was just looking for a quick solution which give users who use James >> 2.3 not to much headach. > > i think that should be possible > > i think that using sieve to deliver IMAP mail is wrong. i think that > the script should set attributes on the mail (for example, set a > attribute for folder) and with independent delivery. > >> But I think you are right, the current MailRepository stuff is really >> bad in terms of Performance. > > 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.. > > 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). > 4. there are subtle semantic differences between the meanings of flags > in POP3, SMTP and IMAP > SMTP Flags ? You lost me here.. > 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 > 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 > 3. add full support for flags to IMAP. use custom flags to support > POP3 mailboxing correctly. > +1 > so, we'd lose a general interface but gain interoperability between > the protocols. > > - robert > Sounds really good.. Bye, Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
