Stefano Bagnara wrote:
2010/2/11 Oleg Kalnichevski <[email protected]>:
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.
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.
There are tons of interfaces in JRE especially for newer stuff, so I am
not sure this is a very convincing argument.
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.
Stefano
I am too old for doing work someone is absolutely determined to undo, so
I will not bother. I have no problem of what so ever putting together a
very simple DOM-like library based on mime4j for my personal projects.
The trouble is that I will no longer be able to continue working towards
0.7 release and some one will have to take over from here.
I am also getting really worried that given the current pace there is
absolutely no hope of API stable mime4j any time soon. This makes me
think about dropping dependency on mime4j in HttpClient. HttpMime uses
just a fraction of mime4j functionality, mostly high level, which tends
to change a lot. It is a shame, really, but with my HttpClient hat on I
cannot help feeling mime4j has become more of a liability.
Having said all that, let's try to be constructive. I will leave all
'message' stuff as is, and will _try_ to come up with default
implementations for methods in that high level DOM classes that are
currently abstract, as long as this can be done without re-introducing
dependencies on 'parser' and 'message'. This would enable HttpClient to
depend on 'dom' without needing 'message'. If later on you decide to
throw away those changes, so be it, I will just fork those classes and
that is it.
Cheers
Oleg
