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
