Re: JavaMail and James

[Stefano Bagnara <ap...@bago.org>]

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 <ap...@bago.org> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org