You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mime4j-dev@james.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2014/07/17 15:57:06 UTC
One year after; was Re: [DISCUSSION] make most of mime4j immutable
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 <ol...@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
Re: One year after; was Re: [DISCUSSION] make most of mime4j immutable
Posted by Stan Ioan Eugen <me...@ieugen.ro>.
+1,
Looks good to me. Great work Oleg.
2014-07-17 18:01 GMT+03:00 Stefano Bagnara <ap...@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 <ol...@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 <ol...@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
Re: One year after; was Re: [DISCUSSION] make most of mime4j immutable
Posted by Stefano Bagnara <ap...@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 <ol...@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 <ol...@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