james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [DISCUSSION] make most of mime4j immutable
Date Wed, 15 May 2013 15:11:10 GMT
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


View raw message