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 19:12:08 GMT
Stefano Bagnara wrote:
> 2010/2/11 Oleg Kalnichevski <olegk@apache.org>:
>> 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.
> 
> 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


Mime
View raw message