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: One year after; was Re: [DISCUSSION] make most of mime4j immutable
Date Thu, 17 Jul 2014 15:01:57 GMT
I'm happy to hear you, Oleg!
The changes sounds good to me.

Stefano

PS: the TransformMessage link for 0.7 doesn't work, but I got anyway
the idea looking at your branch samples.

On 17 July 2014 15:57, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Thu, 2013-05-16 at 14:20 +0200, Oleg Kalnichevski wrote:
>> On Thu, 2013-05-16 at 13:41 +0200, Stefano Bagnara wrote:
>> > 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 ;-)
>> >
>>
>> The reason why we ought not do it by default is to ensure the user is
>> aware of implications of having content overflowing to a temporary
>> persistent storage potentially accessible by other users, processes,
>> etc.
>>
>> > > 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!
>> >
>>
>> A volatile flag may need to get flipped but as far as the consumer is
>> concerned the object remains in _exactly_ the same state as before.
>>
>> >
>> > 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!
>>
>> I'll be on vacation next week and likely to get sucked in by HC related
>> stuff afterwards. We'll see where we stand in a few months.
>>
>> Oleg
>>
>
> Folks
>
> I happen to have a few spare cycles I could invest into mime4j 0.8 and
> would like to take my work on it to a logical conclusion of a sort
> (either by reverting my changes or completing DOM API re-design I have
> started one year ago).
>
> I decided to not pursue the idea of immutable DOM objects any further
> (at least for now) given its potentially disruptive effect on the
> existing code base. I chose to keep DOM objects mutable but move complex
> field generation logic to new builders (with fluent interface) instead
> making DOM objects behave more like normal beans (value objects).
>
> You can find those new builder classes below
>
> https://github.com/apache/james-mime4j/blob/trunk/dom/src/main/java/org/apache/james/mime4j/message/SingleBodyBuilder.java
> https://github.com/apache/james-mime4j/blob/trunk/dom/src/main/java/org/apache/james/mime4j/message/MultipartBuilder.java
> https://github.com/apache/james-mime4j/blob/trunk/dom/src/main/java/org/apache/james/mime4j/message/BodyPartBuilder.java
> https://github.com/apache/james-mime4j/blob/trunk/dom/src/main/java/org/apache/james/mime4j/message/MessageBuilder.java
>
> and see them in action here
>
> https://github.com/apache/james-mime4j/blob/trunk/examples/src/main/java/org/apache/james/mime4j/samples/dom/TextPlainMessage.java
> https://github.com/apache/james-mime4j/blob/trunk/examples/src/main/java/org/apache/james/mime4j/samples/dom/MultipartMessage.java
> https://github.com/apache/james-mime4j/blob/trunk/examples/src/main/java/org/apache/james/mime4j/samples/transform/TransformMessage.java
>
> compared to the old APIs
>
> https://github.com/apache/james-mime4j/blob/apache-mime4j-0.7/examples/src/main/java/org/apache/james/mime4j/samples/dom/TextPlainMessage.java
> https://github.com/apache/james-mime4j/blob/apache-mime4j-0.7/examples/src/main/java/org/apache/james/mime4j/samples/dom/MultipartMessage.java
> https://github.com/apache/james-mime4j/blob/apache-mime4j-0.7examples/src/main/java/org/apache/james/mime4j/samples/transform/TransformMessage.java
>
> I have not made any changes to the existing DOM classes yet. If you do
> not like the new design please complain loudly now. We can still
> re-think the whole approach or even revert my changes entirely. However
> if I hear no objections I would like to proceed with making changes to
> the existing DOM classes in, say, one week time.
>
> Oleg

Mime
View raw message