james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: dom / message API inconsistency
Date Thu, 11 Feb 2010 15:25:27 GMT
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.  

> 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 don't think that the w3c.dom/javax.xml.parsers stuff is perfect but
> their patterns are good and very well known so I'm using the principle
> of the least surprise.
> Of course this is just my opinion, I'm just one developer and I'm open
> to discussions (and expecially to "majority" choices).
> Stefano
> PS: please forgive me for using MessageBuilder (a name we already have
> in mime4j) for a new concept instead of using a new name, but I hope
> it's clear I chose MessageBuilder to make a parallel with the
> javax.xml.parsers.DocumentBuilder object.

View raw message