james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stan Ioan Eugen ...@ieugen.ro>
Subject Re: One year after; was Re: [DISCUSSION] make most of mime4j immutable
Date Sun, 10 Aug 2014 08:40:04 GMT
+1,

Looks good to me. Great work Oleg.


2014-07-17 18:01 GMT+03:00 Stefano Bagnara <apache@bago.org>:
> 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



-- 
Ioan Eugen Stan / ieugen.ro

Mime
View raw message