Noel J. Bergman wrote:
Norman Maurer wrote:
JAMES does not use JavaMail for storage (it is bad enough for what we do
use
it for). In fact, with a wee bit of work, JavaMail will be entirely
removed
from the POP3 codepath.
Who said that we remove it entirely ?
From that particular code path? Been on the plans for ages. Absolutely no
need for JavaMail in that particular codepath, since we don't actually need
to process the content at all.
We have the javamailstore repository in trunk which is great code.
But with one major flaw: it depends upon JavaMail, and JavaMail wants to
instantiate the MimeMessage. WE DO NOT NEED A MIMEMESSAGE FOR POP3. We
only need the stream. The code may open doors to using existing stores, but
it won't be as efficient as a native store, nor as reliable, due to its
dependence on JavaMail.
--- Noel
MimeMessage exposes a lot of its internals: extending it and taking care
of protected things a MimeMessage is simply an InputStream a Session and
a bunch of null field.
So I don't see many problems with JavaMail itself: we can improve it, we
can also rewrite its full parsing using mime4j.. the api itself have
limitations but we are far from being limited by it. We have plenty of
improvements we can do without removing JavaMail.
I already did many things to be able to do the SMTP => POP3 path without
having to call the parse() method of MimeMessage: unfortunately I had to
remove a key part for this (the lazy loading of headers only) because of
problems with current repositories and I think this problems will be
solved as soon as we introduce MessageRepositories.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
