Robert Burrell Donkin ha scritto:
(as everyone probably knows by know i'm a huge unfan of javamail so
i've avoided commenting)
I thought there was no need to be a fan or unfan to reply to this
developer. He simply asked how we are using javamail and how coupled is
James to javamail, and I simply replied to his question.
I hope this does not make me a fan or an unfan of javamail ;-)
On Mon, Apr 28, 2008 at 4:42 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
MimeMessages are built in a lazy way when there is a need to parse or alter
the message.
As long as you receive and spool a message without altering its content
then MimeMessage will never be parsed.
We extensively use our MimeMessageWrapper that is an extension of
MimeMessage made to delay the parsing of the headers and the parsing of the
body as much as possible, with the best scenario of no parsing.
one of the issues with the Mail interface is that there are no
bio/nio-friendly methods
I agree.
You should be aware that we anyway currenlty load the full message stream
in a bytearray in memory, so to handle 10 concurrent messages each one of
10MB serialized you'll need at least 100MB only for the buffers (IIRC james
ends up using the double of this memory, but I never analyzed the details).
we should be able to do better than this and i need to do so for IMAP
I agree.
ideas?
Nothing concrete from me. Unfortunately I've yet to see really clean and
interesting proposal about javamail removal, otherwise I'll probably be
the first supporter of this proposal!
Our best plan is still to evolve mime4j to cover all of our usages of
javamail and then to think about replacing javamail with mime4j and
maybe to also write an alternative javamail implementation backed by
mime4j, but this is far from concrete until we realize what is needed in
mime4j and how to expose interfaces that will be good both in nio and
bio scenario and good in SEDA/standard architectures, good in streaming
and "random access" scenario. We have a lot of completely different
scenario and the hard part is define what would be the best thing, not
to write it.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
