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)

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

4. there are subtle semantic differences between the meanings of flags
in POP3, SMTP and IMAP

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:

1. introducing a new messaging style interface specifically for mail delivery
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.
3. add full support for flags to IMAP. use custom flags to support
POP3 mailboxing correctly.

so, we'd lose a general interface but gain interoperability between
the protocols.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to