Mailing-List: contact mime4j-dev-help@james.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mime4j-dev@james.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Subject: Re: dom / message refactoring; was Re: 0.6.2 or 0.7 any time soon?
From: Oleg Kalnichevski <olegk@apache.org>
To: mime4j-dev@james.apache.org
In-Reply-To: <AANLkTiknVj5R0EuAHpAWj7-p6Kpmb220sMvHaTc7VhaO@mail.gmail.com>
References: <4D2C0AEE.5070700@virtualpostman.co.za>
	 <AANLkTi=9V6JtK=+h+yk0vg=HVCbDzTOzK17KO73aXcuX@mail.gmail.com>
	 <AANLkTi=dTShmY9a4u_Pt7dcA59pUq+FCizdPGfX3r8WS@mail.gmail.com>
	 <1294749756.3394.48.camel@ubuntu>
	 <AANLkTinnjh6NbjC11weOQ_cVLrPxGTDi6oA7+_ex9-MH@mail.gmail.com>
	 <1294753533.3394.79.camel@ubuntu>
	 <AANLkTi=s95F2R+DGWDAt8CvBdsKiCebrCOPN-Q0aLDEH@mail.gmail.com>
	 <1294759001.3394.104.camel@ubuntu>
	 <AANLkTi=yW4iSDk99LOQ=89n2SaY++nYnUV5gHF28ypK-@mail.gmail.com>
	 <1294776829.1849.8.camel@ubuntu> <1295282617.2126.61.camel@ubuntu>
	 <AANLkTiknVj5R0EuAHpAWj7-p6Kpmb220sMvHaTc7VhaO@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 18 Jan 2011 21:43:14 +0100
Message-ID: <1295383394.1937.74.camel@ubuntu>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Tue, 2011-01-18 at 17:46 +0100, Stefano Bagnara wrote:
> Il 17 gennaio 2011 17.43.37 UTC+1, Oleg Kalnichevski
> <olegk@apache.org> ha scritto:
> > Stefano et al
> >
> > Please review another round of API changes on the refactoring branch.
> > Here is the gist of most important changes
> >
> > * Most of the object model implementation logic moved from 'dom' to
> > 'message'. 'dom' consists mostly of pure interfaces now that do not
> > impose particular internal structures, a particular implementation or a
> > particular inheritance hierarchy.
> 
> I think we loose an opportunity to keep backward compatibility in
> future when we want to add methods to the 4 classes you transformed in
> interfaces and I don't see advantages in turn, but, on the other side
> I think we should feel free to break backward compatibility even in
> future versions so this is not a big drawback and I can live with the
> change (just hoping this won't be a blocker in future).
> 

Stefano

I understand the downside of having a pure interface based API. However,
you seem to be very keen to position mime4j not only as a utility for
parsing and building mime messages but also as an abstract Document
Object Model with different / alternative implementations. I just do not
see how one can honestly call the existing code in trunk an abstract
Object Model if the only aspect that is abstract is field parsing. We
should either drop the pretense at having an abstract DOM in mime4j and
revert to the state existed before your changes or actually make an
effort to define a truly abstract model even if that means more effort.

I am very fine with just reverting to the old state, by the way.

So, what shall I do?

> > * All dom element copy / parse logic moved from individual classes to a
> > utility class currently called MimeBuilder (I would prefer this class to
> > be called MessageBuilder but this name is already taken)
> 
> Maybe we should expose some of the MimeBuilder methods via the
> MessageBuilder "public" factory: the bigger limit of the current DOM
> api is that it doesn't expose methods to create a structured Message
> from scratch (it let you set a new Body but it doesn't give a way to
> create a Body). So the MimeBuilder methods could already be moved to
> MessageBuilderImpl. BTW I'm just loud thinking, just go ahead with
> your plan :-)
> 

I am going to get there shortly. I just prefer to make potentially
contentious changes in small, incremental steps, so that they are easier
to review and agree / disagree upon.

Oleg