On Thu, 2010-02-11 at 15:53 +0100, Stefano Bagnara wrote: > 2010/2/11 Oleg Kalnichevski <[email protected]>: > > 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. Oleg > 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. >
