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: dom / message API inconsistency
Date Thu, 11 Feb 2010 16:27:43 GMT
2010/2/11 Oleg Kalnichevski <olegk@apache.org>:
> On Thu, 2010-02-11 at 15:53 +0100, Stefano Bagnara wrote:
>> 2010/2/11 Oleg Kalnichevski <olegk@apache.org>:
>> > In my opinion we should either make DOM API truly abstract by making
>> > Message, Multipart, Header and friends interfaces or give up any
>> > pretense at DOM being an abstract API, which it is clearly not.
>> Well, Multipart is already abstract and in the dom. Header is not used
>> anywhere (ATM). Message have an abstract code.
> Just declaring stuff abstract, does not not necessarily make it
> abstract, does it? Even though those classes are declared abstract they
> have too much implementation specific code in them to be truly abstract
> in terms of being implementation neutral. At the moment those classes
> are not abstract, they are useless (without 'message' impls).
>>  About using abstract
>> classes instead of interfaces this is a design choices: there are
>> pros/cons. With abstract classes you can add methods later without
>> breaking implementations. An interface only API will break
>> compatibility at every change (that's why I chose to start with
>> abstract for many classes).
> One cannot add new abstract methods without breaking API compatibility,
> so I do not see much of a difference here.

The main difference is that you can add new methods with a default
implementation. If you care of binary compatibility this is a major
difference (but I understand that it make no sense to start talking of
binary compatibility now that we are still moving around classes).
Most JVM classes are not interfaces because of this difference.

>> What I did was a first step towards the first solution. I agree it is
>> not complete, and to complete it we have to take design decisions like
>> these:
>> 1) ParsedField isValidField/getParseException should be really part of
>> the dom or a dom should only represent valid content?
>> 2) Do we want to mimic the xml stuff so provide a MessageBuilder (not
>> the MessageBuilder we have now but a MessageBuilder similar to the xml
>> DocumentBuilder.. and maybe a MessageBuilderFactory) with a parse
>> method that return a Message? or what else?
>> 3) About message serialization: "object.writeTo" allow for
>> optimizations when the implementation knows original bytes for parsed
>> data. MessageWriter, instead is more similar to the
>> javax.xml.transform.Transformer stuff (well, we could even have a
>> "Writeable" interface and when MessageWriter finds writable objects it
>> optimize the writing process (didn't think about this too much).
>> IMO the goal is to have a mime dom manipulation library not depending
>> on the parser: this would make the mime4j architecture more clear. TO
>> make the "dom" usable we just need a MessageBuilder (and maybe
>> MessageBuilderFactory) object. My use case is:
>> MessageBuilder mb = MessageBuilderFactory.newMessageBuilder();
>> Message m = mb.parse(InputrStream);
>> Also, I'd like to have a MessageBuilder.newMessage instead of new MessageImpl().
>> At this point I should be able to use/alter the message without using
>> the message/field packages, but only the dom package.
> Ability to use 'dom' package to generate messages without depending on
> the 'parser' package is a great idea, which I fully support, but the
> current state of things does not take us any further towards that goal
> than before the refactoring.

I think a roadmap is made by steps. Most time you need multiple steps
to reach a good results, but this doesn't mean you should not move
your feets until you know you can jump to the good results.

That said if you want to merge back the packages I don't care (I
*really* don't like this, but I can accept it). I will split them once
I will have the time for a longer step.


View raw message