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 Thu, 16 May 2013 10:54:37 GMT
On Thu, 2013-05-16 at 10:59 +0200, Stefano Bagnara wrote:
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.
> 
> 

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


Mime
View raw message