Mailing-List: contact mime4j-dev-help@james.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mime4j-dev@james.apache.org
Received-SPF: pass (athena.apache.org: domain of apache@bago.org designates
 74.125.82.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1295383394.1937.74.camel@ubuntu>
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>
	<1295383394.1937.74.camel@ubuntu>
Date: Tue, 18 Jan 2011 22:41:09 +0100
Message-ID: <AANLkTi=R9Z9497QALxRAxz=D4SFn9u-q+vq3JOYfUVbp@mail.gmail.com>
Subject: Re: dom / message refactoring; was Re: 0.6.2 or 0.7 any time soon?
From: Stefano Bagnara <apache@bago.org>
To: mime4j-dev <mime4j-dev@james.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

2011/1/18 Oleg Kalnichevski <olegk@apache.org>:
> 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?

Go ahead with your plan.

I agree that DOM is incomplete now.

I don't think that we'll see alternative implementations, but having a
good DOM api is also a way to stabilize an interface and put a clear
limit in what can be changed and what cannot be changed.

I would like before 1.0 to tell people feel free to refer .dom.
classes, don't touch .field./.message./.storage./ .

Having no direct dependencies from dom to the implementation is a way
to be sure this happen.

>> [...] 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.

I understand. I'm impatient to see your changes :-)

Happy hacking
Stefano