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: MessageBuilder refactoring; was Re: dom / message refactoring
Date Tue, 25 Jan 2011 16:49:54 GMT
2011/1/25 Oleg Kalnichevski <olegk@apache.org>:
> ...
>> >> [...] 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 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

> * 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 (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.

Thank you,

View raw message