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 14:53:32 GMT
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. 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).

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

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).


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