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