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 2013/03/26 21:13:05 UTC
Re: [DISCUSSION] make most of mime4j immutable
On Mon, 2012-09-03 at 00:14 +0300, Ioan Eugen Stan wrote:
> Hello,
>
> After looking around in mime4j I noticed that most of the API
> interfaces from mime4j-dom provide getters and are mutable. This means
> that implementations are also not thread safe.
>
> I propose we move to an Immutable API implementation with nice
> builders. This will make things thread safe and make life easier for
> our users.
>
> This will most likely mean a change in the API.
>
> I think this is worth it, as we may have less bugs in our
> (multi-threaded) code. What do you think?
>
> Cheers,
>
Ioan, et al
What happened to this idea? Is anyone still planning to work on
redesigning DOM APIs? If not, I might be willing to step in.
Cheers
Oleg
Re: [DISCUSSION] make most of mime4j immutable
Posted by Ioan Eugen Stan <st...@gmail.com>.
On Wed, May 15, 2013 at 8:59 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Wed, 2013-05-15 at 18:24 +0200, Stefano Bagnara wrote:
>> 2013/5/15 Oleg Kalnichevski <ol...@apache.org>:
>> > (1) Do nothing. While the present DOM API is not fancy and fluid and all
>> > it works.
>> > (2) Make DOM elements (almost) immutable but keep the existing
>> > Disposable model at the expense of having a few fringe cases when the
>> > same body part instance can end up referenced by multiple Message
>> > objects. Disposal of one message will inadvertently render other
>> > instances' state invalid.
>>
>> In order to better judge the best option I would have to understand
>> what immutability bring us.
>> I don't care at all that a single element could be shared between
>> messages or that a single message (or part of it) could be manipulated
>> concurrently by multiple threads.
>> On the other side I care of clean/simple API.
>>
>
> There is more to immutability than just thread safety. Immutable objects
> are always guaranteed to be in a consistent state. Always. This is
> actually quite nice once you come to depend on it.
Yes, this pays off mostly with concurrency, but it also impacts the API design.
Having immutable state makes me more relaxed because I have to worry
less about concurrency issues.
> This is currently a trend and trends may pass but there is a common
> belief that builder fluent pattern suits well for initialization of
> complex objects with many various dependencies. JAX-RS API could be a
> good example of that.
Yes, trends may pass but immutability and functional design with no
shared state are better suited for concurrent and multi
processor/cores programming. Nobody can change the object so you are
free to share it across all cores/threads => no need to synchronize.
>> Can you provide a snippet of code for the current API that you don't
>> like and how you expect it to be after an immutable/almostimmutable
>> refactoring?
>>
>
> It is not the best example but something that actually works already
>
> before refactoring
> https://svn.apache.org/repos/asf/james/mime4j/tags/apache-mime4j-project-0.7/dom/src/main/java/org/apache/james/mime4j/message/BasicBodyFactory.java
>
> after refactoring
> https://svn.apache.org/repos/asf/james/mime4j/trunk/dom/src/main/java/org/apache/james/mime4j/message/BasicBodyFactory.java
>
>
>> > (3) Reconsider resource management concept. One possibility would be to
>> > move responsibility for resource disposal from DOM elements to Storage
>> > manager.
>>
>> If I understand it, this would always expose the Storage manager to
>> the DOM user.
>>
>> I find this is a frequent DOM use case:
>>
>> try {
>> message = messageBuilder.parseMessage(new EOLConvertingInputStream(is));
>> } catch (...) {
>> ...
>> } finally {
>> message.dispose();
>> }
>>
>
> Absolutely not. On the contrary those users who do not need special
> storage would no longer have to dispose of Message objects.
>
>
>> This code currently uses the dom package and doesn't even know a
>> storage package exists.
>
> That's the whole point. We have a situation when a requirement relevant
> for a fraction of user population imposes design decisions that impact
> ALL users.
I agree with you reasoning here. Messages should not dispose
themselves and we should do well to keep them free of resources that
need to be properly disposed (InputStreams and such).
>> You could pass a different messageBuilder (using an advanced storage
>> technique) to this code and it should works the same way... are you
>> suggesting that every dom users should be forced to deal with a
>> storage manager to tell when it's done working with a message? Can you
>> make an example?
>>
>
> That's how it could look (warning: it is pseudo-code)
I like the way it builds up. Nice.
> ---
> StorageManager sm = new SomeStorageManager();
> try {
> Message m1 = new MessageBuilder()
> .setStorageManager(sm)
> .parse(stream)
> .build();
>
> Message m2 = new MessageBuilder()
> .setStorageManager(sm)
> .parse(stream)
> .addThis()
> .changeThat().
> .build();
>
> Message m3 = new MessageBuilder()
> .setStorageManager(sm)
> .copy(m2)
> .addMore()
> .build();
>
> // force disposal of a message, if required
> sm.dispose(m2);
> // Message m3 should still remain in a consistent state
>
> } finally {
> // Disposes of resources held by Message m1 and m3
> sm.close();
> }
> ---
>
> Oleg
>
--
Ioan Eugen Stan
0720 898 747
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
One year after; was Re: [DISCUSSION] make most of mime4j immutable
Posted by Oleg Kalnichevski <ol...@apache.org>.
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: [DISCUSSION] make most of mime4j immutable
Posted by Oleg Kalnichevski <ol...@apache.org>.
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
Re: [DISCUSSION] make most of mime4j immutable
Posted by Stefano Bagnara <ap...@bago.org>.
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 ;-)
> 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!
Stefano
Re: [DISCUSSION] make most of mime4j immutable
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2013-05-16 at 10:59 +0200, Stefano Bagnara wrote:
2013/5/15 Oleg Kalnichevski <ol...@apache.org>:
> > There is more to immutability than just thread safety. Immutable
objects
> > are always guaranteed to be in a consistent state. Always. This is
> > actually quite nice once you come to depend on it.
>
> I know what immutability brings, generally, and I also developed
> something in Scala where I appreciate a lot the model.
> Yet, I'm not sure this means immutability is always the best approach
> to any problem (expecially if you still work in OOP).
> That said, I see you and Ioan agree on this approach, so just go
> ahead! I'm just here to review and bring my 2 cents ;-)
>
> >> If I understand it, this would always expose the Storage manager to
> >> the DOM user.
> >> [...]
> > Absolutely not. On the contrary those users who do not need special
> > storage would no longer have to dispose of Message objects.
>
> What I mean is that my code, for example jDKIM, uses that message
> creation (via parsing) and disposal at the end of processing and
> doesn't care how the resources are handled by mime4j
> This gives us an option to have a better default strategy where big
> messages are stored in filesystems by default without the user having
> to care about a StorageManager and similar thing.
>
> 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.
If I don't add storage manager management to the jDKIM library then a
> jDKIM user won't be able to dispose a message because that message is
> not exposed to the jDKIM user but only used inside it.
>
> Another point is that currently the DOM API allowed me to return a
> Message with "unparsed" contents and let it parse "on-demand" / lazily
> (e.g: in James Server we do something similar by overriding the
> JavaMail MimeMessage to lazily load the body on demand and we deal
> with disposition). The same happens for Field values that could be
> parsed lazily. I fear that immutability will limit the scope of the
> library.
>
>
That would not need to change. Lazy parsing would not need to go away.
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.
>> This code currently uses the dom package and doesn't even know a
> >> storage package exists.
> >
> > That's the whole point. We have a situation when a requirement
relevant
> > for a fraction of user population imposes design decisions that
impact
> > ALL users.
>
> Maybe we have different opinions on the "fraction" ;-) Maybe I used
> mime4j in 4 different projects and 3 of them would have to be changed
> to use the StorageManager and maybe to *expose* the StorageManager to
> the upper user. Instead I still read "multithreading"/"object sharing"
> in your messages and I consider this feature would benefit a very
> small fraction of mime4j users.
>
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.
> That said I don't have the time to bring constructive contributions to
> the refactoring. I trust you and your coder skills, so just go ahead
> with your plan.
>
I do not use mime4j DOM much myself. I am quite OK with leaving things
as they currently stand.
Oleg
Re: [DISCUSSION] make most of mime4j immutable
Posted by Stefano Bagnara <ap...@bago.org>.
2013/5/15 Oleg Kalnichevski <ol...@apache.org>:
> There is more to immutability than just thread safety. Immutable objects
> are always guaranteed to be in a consistent state. Always. This is
> actually quite nice once you come to depend on it.
I know what immutability brings, generally, and I also developed
something in Scala where I appreciate a lot the model.
Yet, I'm not sure this means immutability is always the best approach
to any problem (expecially if you still work in OOP).
That said, I see you and Ioan agree on this approach, so just go
ahead! I'm just here to review and bring my 2 cents ;-)
>> If I understand it, this would always expose the Storage manager to
>> the DOM user.
>> [...]
> Absolutely not. On the contrary those users who do not need special
> storage would no longer have to dispose of Message objects.
What I mean is that my code, for example jDKIM, uses that message
creation (via parsing) and disposal at the end of processing and
doesn't care how the resources are handled by mime4j
This gives us an option to have a better default strategy where big
messages are stored in filesystems by default without the user having
to care about a StorageManager and similar thing.
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.
If I don't add storage manager management to the jDKIM library then a
jDKIM user won't be able to dispose a message because that message is
not exposed to the jDKIM user but only used inside it.
Another point is that currently the DOM API allowed me to return a
Message with "unparsed" contents and let it parse "on-demand" / lazily
(e.g: in James Server we do something similar by overriding the
JavaMail MimeMessage to lazily load the body on demand and we deal
with disposition). The same happens for Field values that could be
parsed lazily. I fear that immutability will limit the scope of the
library.
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...
>> This code currently uses the dom package and doesn't even know a
>> storage package exists.
>
> That's the whole point. We have a situation when a requirement relevant
> for a fraction of user population imposes design decisions that impact
> ALL users.
Maybe we have different opinions on the "fraction" ;-) Maybe I used
mime4j in 4 different projects and 3 of them would have to be changed
to use the StorageManager and maybe to *expose* the StorageManager to
the upper user. Instead I still read "multithreading"/"object sharing"
in your messages and I consider this feature would benefit a very
small fraction of mime4j users.
That said I don't have the time to bring constructive contributions to
the refactoring. I trust you and your coder skills, so just go ahead
with your plan.
Stefano
PS: If you need/like to better understand some of my "objections" I'll
find the time to answer, of course!
Re: [DISCUSSION] make most of mime4j immutable
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2013-05-15 at 18:24 +0200, Stefano Bagnara wrote:
> 2013/5/15 Oleg Kalnichevski <ol...@apache.org>:
> > (1) Do nothing. While the present DOM API is not fancy and fluid and all
> > it works.
> > (2) Make DOM elements (almost) immutable but keep the existing
> > Disposable model at the expense of having a few fringe cases when the
> > same body part instance can end up referenced by multiple Message
> > objects. Disposal of one message will inadvertently render other
> > instances' state invalid.
>
> In order to better judge the best option I would have to understand
> what immutability bring us.
> I don't care at all that a single element could be shared between
> messages or that a single message (or part of it) could be manipulated
> concurrently by multiple threads.
> On the other side I care of clean/simple API.
>
There is more to immutability than just thread safety. Immutable objects
are always guaranteed to be in a consistent state. Always. This is
actually quite nice once you come to depend on it.
This is currently a trend and trends may pass but there is a common
belief that builder fluent pattern suits well for initialization of
complex objects with many various dependencies. JAX-RS API could be a
good example of that.
> Can you provide a snippet of code for the current API that you don't
> like and how you expect it to be after an immutable/almostimmutable
> refactoring?
>
It is not the best example but something that actually works already
before refactoring
https://svn.apache.org/repos/asf/james/mime4j/tags/apache-mime4j-project-0.7/dom/src/main/java/org/apache/james/mime4j/message/BasicBodyFactory.java
after refactoring
https://svn.apache.org/repos/asf/james/mime4j/trunk/dom/src/main/java/org/apache/james/mime4j/message/BasicBodyFactory.java
> > (3) Reconsider resource management concept. One possibility would be to
> > move responsibility for resource disposal from DOM elements to Storage
> > manager.
>
> If I understand it, this would always expose the Storage manager to
> the DOM user.
>
> I find this is a frequent DOM use case:
>
> try {
> message = messageBuilder.parseMessage(new EOLConvertingInputStream(is));
> } catch (...) {
> ...
> } finally {
> message.dispose();
> }
>
Absolutely not. On the contrary those users who do not need special
storage would no longer have to dispose of Message objects.
> This code currently uses the dom package and doesn't even know a
> storage package exists.
That's the whole point. We have a situation when a requirement relevant
for a fraction of user population imposes design decisions that impact
ALL users.
> You could pass a different messageBuilder (using an advanced storage
> technique) to this code and it should works the same way... are you
> suggesting that every dom users should be forced to deal with a
> storage manager to tell when it's done working with a message? Can you
> make an example?
>
That's how it could look (warning: it is pseudo-code)
---
StorageManager sm = new SomeStorageManager();
try {
Message m1 = new MessageBuilder()
.setStorageManager(sm)
.parse(stream)
.build();
Message m2 = new MessageBuilder()
.setStorageManager(sm)
.parse(stream)
.addThis()
.changeThat().
.build();
Message m3 = new MessageBuilder()
.setStorageManager(sm)
.copy(m2)
.addMore()
.build();
// force disposal of a message, if required
sm.dispose(m2);
// Message m3 should still remain in a consistent state
} finally {
// Disposes of resources held by Message m1 and m3
sm.close();
}
---
Oleg
Re: [DISCUSSION] make most of mime4j immutable
Posted by Stefano Bagnara <ap...@bago.org>.
2013/5/15 Oleg Kalnichevski <ol...@apache.org>:
> (1) Do nothing. While the present DOM API is not fancy and fluid and all
> it works.
> (2) Make DOM elements (almost) immutable but keep the existing
> Disposable model at the expense of having a few fringe cases when the
> same body part instance can end up referenced by multiple Message
> objects. Disposal of one message will inadvertently render other
> instances' state invalid.
In order to better judge the best option I would have to understand
what immutability bring us.
I don't care at all that a single element could be shared between
messages or that a single message (or part of it) could be manipulated
concurrently by multiple threads.
On the other side I care of clean/simple API.
Can you provide a snippet of code for the current API that you don't
like and how you expect it to be after an immutable/almostimmutable
refactoring?
> (3) Reconsider resource management concept. One possibility would be to
> move responsibility for resource disposal from DOM elements to Storage
> manager.
If I understand it, this would always expose the Storage manager to
the DOM user.
I find this is a frequent DOM use case:
try {
message = messageBuilder.parseMessage(new EOLConvertingInputStream(is));
} catch (...) {
...
} finally {
message.dispose();
}
This code currently uses the dom package and doesn't even know a
storage package exists.
You could pass a different messageBuilder (using an advanced storage
technique) to this code and it should works the same way... are you
suggesting that every dom users should be forced to deal with a
storage manager to tell when it's done working with a message? Can you
make an example?
Stefano
Re: [DISCUSSION] make most of mime4j immutable
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2013-03-27 at 00:09 +0200, Ioan Eugen Stan wrote:
> Hello Oleg,
>
> Pleas do. I've migrated around James components a lot. My focus for
> now is on releasing 3.0.0 and updating the website infrastructure and
> documentation.
> My coding time is very limited, but I'll be more than happy to assist
> you with ideas, code review, push for releases and integrate changes
> in James Server components.
> If you have time look at the way Jackson API is built [1],[2]. It's
> immutable and has a nice API. Documentation and examples are also
> needed. Especially regarding what RFC's we are implementing and what
> RFC's are related to this issue.
>
> Cheers,
>
> [1] https://github.com/FasterXML/jackson-core
> [2] http://wiki.fasterxml.com/JacksonInFiveMinutes
>
Ioan, et al
Things turned out to be be significantly more complex that I had
initially anticipated. There are several aspects of the current mime4j
DOM model that do not lend themselves well to a design based on the
concept of immutable data objects and mutator (builder) objects.
Firstly, I completely overlooked the fact that MIME body parts can be
disposable and as such need to maintain mutable state. This alone kills
the whole idea. Secondly, mime entities that make up a DOM hierarchy
need to be able to trace their parentage in some cases (for instance to
resolve the default content type). The parent reference is presently
injected to the child objects post construction time thus mandating
their being mutable. While I still think the latter problem can resolved
and parent reference could be made unnecessary, the former would be
massively more difficult to resolve. We would need to re-visit the old
(and rather painful) discussion concerning the overall concept of
resource management in mime4j DOM and likely make significant changes to
the storage module as well. This sounds too much for me right now. All I
can do right is to present you with a number of options we could pursue
and if we all manage to reach a consensus to take another stab at DOM
API redesign in a few months.
(1) Do nothing. While the present DOM API is not fancy and fluid and all
it works.
(2) Make DOM elements (almost) immutable but keep the existing
Disposable model at the expense of having a few fringe cases when the
same body part instance can end up referenced by multiple Message
objects. Disposal of one message will inadvertently render other
instances' state invalid.
(3) Reconsider resource management concept. One possibility would be to
move responsibility for resource disposal from DOM elements to Storage
manager.
Oleg
Re: [DISCUSSION] make most of mime4j immutable
Posted by Ioan Eugen Stan <st...@gmail.com>.
Hi,
Considering version 1.x should come when API is stable I don't object
to breaking API compatibility if it's for a good reason.
Cheers,
On Mon, May 13, 2013 at 6:11 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Wed, 2013-03-27 at 00:09 +0200, Ioan Eugen Stan wrote:
>> Hello Oleg,
>>
>> Pleas do. I've migrated around James components a lot. My focus for
>> now is on releasing 3.0.0 and updating the website infrastructure and
>> documentation.
>> My coding time is very limited, but I'll be more than happy to assist
>> you with ideas, code review, push for releases and integrate changes
>> in James Server components.
>> If you have time look at the way Jackson API is built [1],[2]. It's
>> immutable and has a nice API. Documentation and examples are also
>> needed. Especially regarding what RFC's we are implementing and what
>> RFC's are related to this issue.
>>
>> Cheers,
>>
>> [1] https://github.com/FasterXML/jackson-core
>> [2] http://wiki.fasterxml.com/JacksonInFiveMinutes
>>
>
> Ioan et al
>
> I am about to take the first cut at the DOM API redesign. If no
> objections are raised I am planning to do it on trunk and _without_
> preserving backward compatibility with 0.7. If you would rather prefer
> me to work on a branch (or keep deprecated 0.7 DOM APIs in place) please
> do let me know.
>
> I also would like to make MimeConfig immutable which cannot be done
> without breaking API compatibility. Please complain loudly if you think
> it is not OK.
>
> Oleg
>
--
Ioan Eugen Stan
0720 898 747
Re: [DISCUSSION] make most of mime4j immutable
Posted by Ioan Eugen Stan <st...@gmail.com>.
Nice API Oleg! Looks very good.
On Tue, May 14, 2013 at 2:11 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Mon, 2013-05-13 at 21:20 +0200, Stefano Bagnara wrote:
>> 2013/5/13 Oleg Kalnichevski <ol...@apache.org>:
>> > I am about to take the first cut at the DOM API redesign. If no
>> > objections are raised I am planning to do it on trunk and _without_
>> > preserving backward compatibility with 0.7. If you would rather prefer
>> > me to work on a branch (or keep deprecated 0.7 DOM APIs in place) please
>> > do let me know.
>>
>> +1 to work in trunk: branches are only an overhead when there is a
>> single active developer ;-)
>>
>> > I also would like to make MimeConfig immutable which cannot be done
>> > without breaking API compatibility. Please complain loudly if you think
>> > it is not OK.
>>
>> When you say immutable do you mean you want to move everything from
>> setters (8 properties) to a long list of constructor arguments? Or
>> something else?
>>
>> I hope to find some time to test the updated code against my products
>> and report any broken use case, if any, before 0.8 release so we can
>> fix them.
>>
>> Not sure what you're going to do, but please take into consideration
>> the way we use MimeConfig in jDKIM:
>> -----
>> private MessageServiceFactory newMessageBuilder() throws MimeException {
>> MimeConfig mec = new MimeConfig();
>> mec.setMaxLineLen(10000);
>> mec.setMaxHeaderLen(30000);
>>
>> MessageServiceFactory mbf = MessageServiceFactory.newInstance();
>> mbf.setAttribute("MimeEntityConfig", mec);
>> mbf.setAttribute("FlatMode", true);
>> mbf.setAttribute("ContentDecoding", false);
>>
>> return mbf;
>> }
>> -------
>> Here is another use case where I used MimeConfig in a customer project:
>> -------
>> MimeConfig mimeEntityConfig = new MimeConfig();
>> mimeEntityConfig.setStrictParsing(false);
>> mimeEntityConfig.setMaxLineLen(10240);
>> MessageServiceFactory factory = MessageServiceFactory.newInstance();
>> factory.setAttribute("StorageProvider", new MemoryStorageProvider());
>> factory.setAttribute("MimeEntityConfig", mimeEntityConfig);
>> factory.setAttribute("DecodeMonitor", new CheckHandlerDecodeMonitor(eh));
>> MessageBuilder builder = factory.newMessageBuilder();
>> Message message = builder.parseMessage(is);
>> ------
>> And I also attach another snippet using MimeConfig, too.
>>
>> I don't expect everything to remaing unchanged and of course I'm ready
>> to update my code to mime4j changes, but I prefer to report the use
>> cases in advance, for reference.
>>
>> If you prefer to commit the changes before explaining what is your
>> plan with MimeConfig immutability please go ahead (maybe it's easier
>> for you to commit the change than explaining it).
>>
>> Stefano
>
> Stefano
>
> With the new API the same config code would look like
> ---
> MimeConfig mec = MimeConfig.custom();
> .setMaxLineLen(10000)
> .setMaxHeaderLen(30000)
> .build();
> ---
> The benefit of having immutable config is that the same object can be
> passed around without a risk of some component altering the config at
> runtime and impacting other components or having to create a clone each
> and every time. So, instead of creating new instances of MimeConfig with
> default settings one can use MimeConfig#DEFAULT or MimeConfig#STRICT.
>
> One can alter an existing MimeConfig instance by doing that
> ---
> MimeConfig mec = MimeConfig.copy(MimeConfig.STRICT);
> .setMaxLineLen(10000)
> .setMaxHeaderLen(30000)
> .build();
> ---
>
> Oleg
>
--
Ioan Eugen Stan
0720 898 747
Re: [DISCUSSION] make most of mime4j immutable
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2013-05-13 at 21:20 +0200, Stefano Bagnara wrote:
> 2013/5/13 Oleg Kalnichevski <ol...@apache.org>:
> > I am about to take the first cut at the DOM API redesign. If no
> > objections are raised I am planning to do it on trunk and _without_
> > preserving backward compatibility with 0.7. If you would rather prefer
> > me to work on a branch (or keep deprecated 0.7 DOM APIs in place) please
> > do let me know.
>
> +1 to work in trunk: branches are only an overhead when there is a
> single active developer ;-)
>
> > I also would like to make MimeConfig immutable which cannot be done
> > without breaking API compatibility. Please complain loudly if you think
> > it is not OK.
>
> When you say immutable do you mean you want to move everything from
> setters (8 properties) to a long list of constructor arguments? Or
> something else?
>
> I hope to find some time to test the updated code against my products
> and report any broken use case, if any, before 0.8 release so we can
> fix them.
>
> Not sure what you're going to do, but please take into consideration
> the way we use MimeConfig in jDKIM:
> -----
> private MessageServiceFactory newMessageBuilder() throws MimeException {
> MimeConfig mec = new MimeConfig();
> mec.setMaxLineLen(10000);
> mec.setMaxHeaderLen(30000);
>
> MessageServiceFactory mbf = MessageServiceFactory.newInstance();
> mbf.setAttribute("MimeEntityConfig", mec);
> mbf.setAttribute("FlatMode", true);
> mbf.setAttribute("ContentDecoding", false);
>
> return mbf;
> }
> -------
> Here is another use case where I used MimeConfig in a customer project:
> -------
> MimeConfig mimeEntityConfig = new MimeConfig();
> mimeEntityConfig.setStrictParsing(false);
> mimeEntityConfig.setMaxLineLen(10240);
> MessageServiceFactory factory = MessageServiceFactory.newInstance();
> factory.setAttribute("StorageProvider", new MemoryStorageProvider());
> factory.setAttribute("MimeEntityConfig", mimeEntityConfig);
> factory.setAttribute("DecodeMonitor", new CheckHandlerDecodeMonitor(eh));
> MessageBuilder builder = factory.newMessageBuilder();
> Message message = builder.parseMessage(is);
> ------
> And I also attach another snippet using MimeConfig, too.
>
> I don't expect everything to remaing unchanged and of course I'm ready
> to update my code to mime4j changes, but I prefer to report the use
> cases in advance, for reference.
>
> If you prefer to commit the changes before explaining what is your
> plan with MimeConfig immutability please go ahead (maybe it's easier
> for you to commit the change than explaining it).
>
> Stefano
Stefano
With the new API the same config code would look like
---
MimeConfig mec = MimeConfig.custom();
.setMaxLineLen(10000)
.setMaxHeaderLen(30000)
.build();
---
The benefit of having immutable config is that the same object can be
passed around without a risk of some component altering the config at
runtime and impacting other components or having to create a clone each
and every time. So, instead of creating new instances of MimeConfig with
default settings one can use MimeConfig#DEFAULT or MimeConfig#STRICT.
One can alter an existing MimeConfig instance by doing that
---
MimeConfig mec = MimeConfig.copy(MimeConfig.STRICT);
.setMaxLineLen(10000)
.setMaxHeaderLen(30000)
.build();
---
Oleg
Re: [DISCUSSION] make most of mime4j immutable
Posted by Stefano Bagnara <ap...@bago.org>.
2013/5/13 Oleg Kalnichevski <ol...@apache.org>:
> I am about to take the first cut at the DOM API redesign. If no
> objections are raised I am planning to do it on trunk and _without_
> preserving backward compatibility with 0.7. If you would rather prefer
> me to work on a branch (or keep deprecated 0.7 DOM APIs in place) please
> do let me know.
+1 to work in trunk: branches are only an overhead when there is a
single active developer ;-)
> I also would like to make MimeConfig immutable which cannot be done
> without breaking API compatibility. Please complain loudly if you think
> it is not OK.
When you say immutable do you mean you want to move everything from
setters (8 properties) to a long list of constructor arguments? Or
something else?
I hope to find some time to test the updated code against my products
and report any broken use case, if any, before 0.8 release so we can
fix them.
Not sure what you're going to do, but please take into consideration
the way we use MimeConfig in jDKIM:
-----
private MessageServiceFactory newMessageBuilder() throws MimeException {
MimeConfig mec = new MimeConfig();
mec.setMaxLineLen(10000);
mec.setMaxHeaderLen(30000);
MessageServiceFactory mbf = MessageServiceFactory.newInstance();
mbf.setAttribute("MimeEntityConfig", mec);
mbf.setAttribute("FlatMode", true);
mbf.setAttribute("ContentDecoding", false);
return mbf;
}
-------
Here is another use case where I used MimeConfig in a customer project:
-------
MimeConfig mimeEntityConfig = new MimeConfig();
mimeEntityConfig.setStrictParsing(false);
mimeEntityConfig.setMaxLineLen(10240);
MessageServiceFactory factory = MessageServiceFactory.newInstance();
factory.setAttribute("StorageProvider", new MemoryStorageProvider());
factory.setAttribute("MimeEntityConfig", mimeEntityConfig);
factory.setAttribute("DecodeMonitor", new CheckHandlerDecodeMonitor(eh));
MessageBuilder builder = factory.newMessageBuilder();
Message message = builder.parseMessage(is);
------
And I also attach another snippet using MimeConfig, too.
I don't expect everything to remaing unchanged and of course I'm ready
to update my code to mime4j changes, but I prefer to report the use
cases in advance, for reference.
If you prefer to commit the changes before explaining what is your
plan with MimeConfig immutability please go ahead (maybe it's easier
for you to commit the change than explaining it).
Stefano
Re: [DISCUSSION] make most of mime4j immutable
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2013-03-27 at 00:09 +0200, Ioan Eugen Stan wrote:
> Hello Oleg,
>
> Pleas do. I've migrated around James components a lot. My focus for
> now is on releasing 3.0.0 and updating the website infrastructure and
> documentation.
> My coding time is very limited, but I'll be more than happy to assist
> you with ideas, code review, push for releases and integrate changes
> in James Server components.
> If you have time look at the way Jackson API is built [1],[2]. It's
> immutable and has a nice API. Documentation and examples are also
> needed. Especially regarding what RFC's we are implementing and what
> RFC's are related to this issue.
>
> Cheers,
>
> [1] https://github.com/FasterXML/jackson-core
> [2] http://wiki.fasterxml.com/JacksonInFiveMinutes
>
Ioan et al
I am about to take the first cut at the DOM API redesign. If no
objections are raised I am planning to do it on trunk and _without_
preserving backward compatibility with 0.7. If you would rather prefer
me to work on a branch (or keep deprecated 0.7 DOM APIs in place) please
do let me know.
I also would like to make MimeConfig immutable which cannot be done
without breaking API compatibility. Please complain loudly if you think
it is not OK.
Oleg
Re: [DISCUSSION] make most of mime4j immutable
Posted by Ioan Eugen Stan <st...@gmail.com>.
Hello Oleg,
Pleas do. I've migrated around James components a lot. My focus for
now is on releasing 3.0.0 and updating the website infrastructure and
documentation.
My coding time is very limited, but I'll be more than happy to assist
you with ideas, code review, push for releases and integrate changes
in James Server components.
If you have time look at the way Jackson API is built [1],[2]. It's
immutable and has a nice API. Documentation and examples are also
needed. Especially regarding what RFC's we are implementing and what
RFC's are related to this issue.
Cheers,
[1] https://github.com/FasterXML/jackson-core
[2] http://wiki.fasterxml.com/JacksonInFiveMinutes
--
Ioan Eugen Stan