2010/1/22 Robert Burrell Donkin <[email protected]>:
> 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.
True.. I would prefer to just "/dev/null" the whole javamail crap ;)
For SMTP sending (RemoteDelivery) I would be very interested in see an
MINA base delivery mailet ....
>
>>> 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.
+1. The Problem would be the break of the Mailet API. Maybe we can
just add a wrapper to allow the stuff which depends on javamail to
still work..
>
>>> 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.)
You lost me here.. IMAP sets flags based on SMTP ? I don't get it...
>
>>> 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
>
Sounds good :)
>>> 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?
>
Yeah please...
>>> 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
>
Depending on javamail just for flags sounds like something
"suboptimal". Lets roll our own..
>>> so, we'd lose a general interface but gain interoperability between
>>> the protocols.
>>>
>>> - robert
>>>
>>
>> Sounds really good..
>
> great
>
> - robert
>
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
