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 14:23:51 GMT
On Thu, 2010-02-11 at 10:35 +0100, Stefano Bagnara wrote:
> 2010/2/11 Oleg Kalnichevski <olegk@apache.org>:
> > Stefano
> >
> > I am trying to any make sense out of dom / message package split and I
> > just can't.
> I understand, I still have to find a way, too.
> > What is the rationale behind splitting Message, Multipart and related
> > classes?
> >
> > Why does HeaderImpl extend a concrete class, whereas MessageImpl extends
> > an abstract class? Why does Multipart have to be abstract at all? Do we
> > need MultipartImpl at all?
> >
> > Why HeaderImpl, MultipartImpl, and MessageImpl are called impls when
> > they are NOT implementations of an interface but are merely extensions
> > of other classes, some of which are not even abstract? Is such extension
> > really justified?
> >
> > What was the philosophy and the intention behind these API changes?
> dom package include generic code not tied to other mime4j packages and
> mime4j specific parsing.
> IMO it is the quivalent of the org.w3c.dom package.

Presently Dom API is not abstract enough to qualify as an equivalent of
org.w3c.dom, yet missing essential method implementations to be of any
use without message classes. I just cannot help feeling the break-up
into dom and message does not result in any practical benefits.

> This is the only rule I started following when I split the code into
> dom. Previously we had much more mixed environment with the field
> paclage tree containing both implementation details, interface,
> constants, entry points and everything interconnected to the message
> package.
> That said the whole thing is not good, but better than previously. If
> you think the idea behind generic api in the dom package and
> implementation in message/field packages then feel free to go ahead
> and make changes, otherwise let's discuss alternatives.

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.  


> Stefano

View raw message