james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [DISCUSSION] make most of mime4j immutable
Date Thu, 16 May 2013 11:41:10 GMT
2013/5/16 Oleg Kalnichevski <olegk@apache.org>:
> On Thu, 2013-05-16 at 10:59 +0200, Stefano Bagnara wrote:
>> With a similar refactoring you are telling that everyone will be moved
>> to a "all in memory parsing" unless they add support for storage
>> manager in their applications/libraries.
> This is the default mode already.

I know this, but a new release could have included a "fallback to
filesystem over 100KB" strategy by default and the current users
wouldn't need to change a thing.
But maybe we won't ever do a similar thing by default, so you're
convincing me ;-)

> That would not need to change. Lazy parsing would not need to go away.

I don't get how you do both immutable and lazy, but if we can keep
lazy parsing then my main argument goes away and I'm happy to follow
your changes!

> Also, I was expecting DOM API to evolve to become bidirectional, so I
>> could simply parse a message, add an attachment and serialize it again
>> or change the encoding of a part and serialize it again...
> Create a builder, build a message, serialize the message, mutate the
> builder, create another message, serialize that message, repeat if
> needed.

Let me know if I understood:
Let's say I want to just alter the 99th part of the 3rd level of a big
nested mime message so that it is encoded as base64 instead of
uuencoding: in a mutable API I simply do
message[part1][part4][part2][content-transfer-encoding] = 'base64';
With immutability
build a new message (output)
start traversing the input message (input)
unless I'm on "part1.part4.part2" path I simply copy the input in output.
As soon as I reach "part1.part4.part2" I create a new part using the
base64 encoding.
continue with my traversing "clone"

For "trivial" changes this is a lot more work, unless the "mutator" is
really smart doing this for you.
To be honest, you usually already traverse messages to *find* the
things you want to change, so my comparison is not so fair.

> In any heavy duty application one would undoubtedly need to deal with
> large content entities and store them appropriately, but in my opinion
> mime4j DOM is used way more to build messages from scratch rather than
> to parse and modify messages. Streaming API is better for parsing
> messages. Hence my conviction that the current resource management model
> is geared more toward a minority of the user population at the expense
> of a majority.

In my case I always used the dom api for parsing and having a simpler
interface than the parser one.
The current api was not complete enough to be used to build messages, IMHO.

> I do not use mime4j DOM much myself. I am quite OK with leaving things
> as they currently stand.

I suggested you should proceed with the changes you proposed: as I
already wrote I trust your skills and from your answers I see we share
the goals (keep lazy parsing, let people use dom api to build
messages), so there's no reason I should stop you from improving
mime4j! :-)

And just to be sure the are no misunderstanding: in my opinion you can
simply continue to work in SVN even without answering this message!
Code is the best answer, sometimes, and I'm sorry I submit too few
code and too much mailing list posts ;-)  Power to active committers!


View raw message