james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: dom / message API inconsistency
Date Thu, 11 Feb 2010 09:35:46 GMT
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.

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.

Stefano

Mime
View raw message