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
