james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [DISCUSSION] make most of mime4j immutable
Date Wed, 15 May 2013 16:24:08 GMT
2013/5/15 Oleg Kalnichevski <olegk@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

> (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 {

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?


View raw message