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 Thu, 16 May 2013 08:59:49 GMT
2013/5/15 Oleg Kalnichevski <olegk@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!

Mime
View raw message