+1, Looks good to me. Great work Oleg.
2014-07-17 18:01 GMT+03:00 Stefano Bagnara <[email protected]>: > I'm happy to hear you, Oleg! > The changes sounds good to me. > > Stefano > > PS: the TransformMessage link for 0.7 doesn't work, but I got anyway > the idea looking at your branch samples. > > On 17 July 2014 15:57, Oleg Kalnichevski <[email protected]> wrote: >> On Thu, 2013-05-16 at 14:20 +0200, Oleg Kalnichevski wrote: >>> On Thu, 2013-05-16 at 13:41 +0200, Stefano Bagnara wrote: >>> > 2013/5/16 Oleg Kalnichevski <[email protected]>: >>> > > On Thu, 2013-05-16 at 10:59 +0200, Stefano Bagnara wrote: >>> > >> 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. >>> > >>> > I know this, but a new release could have included a "fallback to >>> > filesystem over 100KB" strategy by default and the current users >>> > wouldn't need to change a thing. >>> > But maybe we won't ever do a similar thing by default, so you're >>> > convincing me ;-) >>> > >>> >>> The reason why we ought not do it by default is to ensure the user is >>> aware of implications of having content overflowing to a temporary >>> persistent storage potentially accessible by other users, processes, >>> etc. >>> >>> > > That would not need to change. Lazy parsing would not need to go away. >>> > >>> > I don't get how you do both immutable and lazy, but if we can keep >>> > lazy parsing then my main argument goes away and I'm happy to follow >>> > your changes! >>> > >>> >>> A volatile flag may need to get flipped but as far as the consumer is >>> concerned the object remains in _exactly_ the same state as before. >>> >>> > >>> > I suggested you should proceed with the changes you proposed: as I >>> > already wrote I trust your skills and from your answers I see we share >>> > the goals (keep lazy parsing, let people use dom api to build >>> > messages), so there's no reason I should stop you from improving >>> > mime4j! :-) >>> > >>> > And just to be sure the are no misunderstanding: in my opinion you can >>> > simply continue to work in SVN even without answering this message! >>> > Code is the best answer, sometimes, and I'm sorry I submit too few >>> > code and too much mailing list posts ;-) Power to active committers! >>> >>> I'll be on vacation next week and likely to get sucked in by HC related >>> stuff afterwards. We'll see where we stand in a few months. >>> >>> Oleg >>> >> >> Folks >> >> I happen to have a few spare cycles I could invest into mime4j 0.8 and >> would like to take my work on it to a logical conclusion of a sort >> (either by reverting my changes or completing DOM API re-design I have >> started one year ago). >> >> I decided to not pursue the idea of immutable DOM objects any further >> (at least for now) given its potentially disruptive effect on the >> existing code base. I chose to keep DOM objects mutable but move complex >> field generation logic to new builders (with fluent interface) instead >> making DOM objects behave more like normal beans (value objects). >> >> You can find those new builder classes below >> >> https://github.com/apache/james-mime4j/blob/trunk/dom/src/main/java/org/apache/james/mime4j/message/SingleBodyBuilder.java >> https://github.com/apache/james-mime4j/blob/trunk/dom/src/main/java/org/apache/james/mime4j/message/MultipartBuilder.java >> https://github.com/apache/james-mime4j/blob/trunk/dom/src/main/java/org/apache/james/mime4j/message/BodyPartBuilder.java >> https://github.com/apache/james-mime4j/blob/trunk/dom/src/main/java/org/apache/james/mime4j/message/MessageBuilder.java >> >> and see them in action here >> >> https://github.com/apache/james-mime4j/blob/trunk/examples/src/main/java/org/apache/james/mime4j/samples/dom/TextPlainMessage.java >> https://github.com/apache/james-mime4j/blob/trunk/examples/src/main/java/org/apache/james/mime4j/samples/dom/MultipartMessage.java >> https://github.com/apache/james-mime4j/blob/trunk/examples/src/main/java/org/apache/james/mime4j/samples/transform/TransformMessage.java >> >> compared to the old APIs >> >> https://github.com/apache/james-mime4j/blob/apache-mime4j-0.7/examples/src/main/java/org/apache/james/mime4j/samples/dom/TextPlainMessage.java >> https://github.com/apache/james-mime4j/blob/apache-mime4j-0.7/examples/src/main/java/org/apache/james/mime4j/samples/dom/MultipartMessage.java >> https://github.com/apache/james-mime4j/blob/apache-mime4j-0.7examples/src/main/java/org/apache/james/mime4j/samples/transform/TransformMessage.java >> >> I have not made any changes to the existing DOM classes yet. If you do >> not like the new design please complain loudly now. We can still >> re-think the whole approach or even revert my changes entirely. However >> if I hear no objections I would like to proceed with making changes to >> the existing DOM classes in, say, one week time. >> >> Oleg -- Ioan Eugen Stan / ieugen.ro
