On Tue, 2011-01-25 at 17:49 +0100, Stefano Bagnara wrote: > 2011/1/25 Oleg Kalnichevski <[email protected]>: > > ... > > > >> > >> >> [...] BTW I'm just loud thinking, just go ahead with > >> >> your plan :-) > >> > > >> > I am going to get there shortly. I just prefer to make potentially > >> > contentious changes in small, incremental steps, so that they are easier > >> > to review and agree / disagree upon. > >> > >> I understand. I'm impatient to see your changes :-) > >> > >> Happy hacking > >> Stefano > >> > > > > Stefano et al > > > > I just completed refactoring of MessageBuilder and related classes on > > the refactoring branch. Here is a short summary of changes: > > > > * MessageBuilder redesigned and changed to an interface > > * Moved #writeTo method to MessageWriter interface > > Moving "writeTo" from each "DOM node" to a MessageWriter interface > have the drawback that you cannot anymore serialize just part of a > message (just a subtree, an header, a content) because your > MessageWriter serializes only full messages. On the other side I see > the advantage of having the writer separated from the element itself > (reading and writing are different tasks). >
I am sorry but that was not done by me. http://svn.apache.org/viewvc?view=revision&revision=739822 > I haven't carefully looked at the code to see if you preserved some of > the optimizations about unparsed content streamed as-is in writeTo > instead of being recreated (this was good for performances and also to > keep input formatting when writing out a parsed message with no > changes). > > > * MessageBuilderFactory renamed to MessageServiceFactory and can now be > > used to instantiate message writers and builders. Additional factory > > methods can be introduced in the future. > > > > Please review and let me know if you can live with these changes. > > I hoped you wanted to deal also with DOM altering methods as I thought > you was not happy with dom mainly because it was an incomplete api (so > I probably didn't understand you well). I don't see "improvements" > over previous trunk My main problem was the lack of consistency in your code more than anything else. I never claimed I was able to create a "better" / "enhanced" / "more complete" API. I was merely trying to resolve inconsistencies while preserving the initial design and the general approach that you had started. If I had my way I would simply throw away every single class in the 'dom' packages, especially that horrid ServiceLoader, and reverted back to the simpler Message API that had existed before. > (But maybe this is mainly a matter of style / > different approaches to API design), but it is anyway much better than > 0.6 so I can live with it (power to active people). > > To avoid misunderstandings: I'm not "sad" accepting this changes, on > the contrary I'm happy to see someone pushing mime4j again and I just > try to find the time to review and explain why things were done in > that way. > How do you want me to proceed now? Cheers, Oleg
