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
 209.85.161.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1294753533.3394.79.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>
Date: Tue, 11 Jan 2011 15:18:54 +0100
Message-ID: <AANLkTi=s95F2R+DGWDAt8CvBdsKiCebrCOPN-Q0aLDEH@mail.gmail.com>
Subject: Re: 0.6.2 or 0.7 any time soon? was Re: Incorrect line length
 limitation while parsing headers
From: Stefano Bagnara <apache@bago.org>
To: mime4j-dev <mime4j-dev@james.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

2011/1/11 Oleg Kalnichevski <olegk@apache.org>:
> On Tue, 2011-01-11 at 14:01 +0100, Stefano Bagnara wrote:
>> 2011/1/11 Oleg Kalnichevski <olegk@apache.org>:
>> > On Tue, 2011-01-11 at 09:27 +0100, Norman Maurer wrote:
>> >> Hi there,
>> >>
>> >> I think if it worth it we should release 0.6.2. Release often release
>> >> early, you know ;)
>> >>
>> >> Bye,
>> >> Norman
>> >>
>> >
>> > Folks
>> >
>> > I also would like to port another fix, should we decide to do another
>> > release off the 0.6.x branch.
>>
>> What is the other fix? This one is not critical (I see it just like a
>> documentation bug: either way we need that check on that field to work
>> that way, we can't simply check the line length).
>>
>
> Parsing of folded fields. The default field parser in 0.6 chokes on
> perfectly valid fields if their body is folded.
>
>
>> > I am also willing to make a push toward the 0.7 release, if no one is
>> > going to pick up work on the API changes stared by Stefano on the trunk.
>>
>> I had really few time but I think I also slowed down because I never
>> understood if what I was doing was liked or not. It takes a lot to
>> complete stuff, so I would have liked to understand what others thinks
>> we should do in 0.7.
>>
>> As an example I see sometimes we talk as 0.x versions we can do
>> backward incompatible changes trying to reach a good api, other times
>> it seems we instead are "stuck" to the 0.6 version because 0.6 has
>> already a lot of users so compatibility is brought to the table.
>>
>> That said, I say my opinion and I expect others to say their opinions
>> so that we can see where we can find a consensus.
>> - I think 0.6 is not "great" as API, so I would happily break
>> compatibility in order to provide a better api. Main thing is that the
>> 0.6 API does not accept evolution (every non trivial feature will
>> require a backward incompatible change).
>> - IMO current trunk could be released as 0.7.0 with very minor change:
>> it is far from exposing a complete api, but I find it already better
>> than 0.6 and I have already some product depending on current trunk.
>> We saw we proceed at a slow speed, so we should be prepared improving
>> the API while we reach 1.0.
>> - I guess most of changes we have in trunk are not backportable to 0.6
>> because they have been possible by the major refactorings, but I'm not
>> against this, if anyone sees a way.
>>
>> Can you state yours and also tell something more about "your" 0.7 plan?
>>
>
> I think we discussed this on more than one occasion in the past. While I
> think mime4j 'core' in 0.7 is fine, the 'dom' / 'message' stuff is not,

Yes, we discussed a couple of times, but we didn't find a solution (at
least not one I understood)

> and the whole library is not in a releasable state at the moment.

Got it: hope you will review trunk soon to understand what changes you
propose to make it releasable.

> And there is "my" plan:
>
> (1) ask people to go over issues in JIRA and decide what is in scope for
> 0.7 and what can wait until a better day (0.8)

+1

The main causes I use trunk in production instead of 0.6 are:
MIME4J-158 - Reduce usage of commons-logging in favor of a "Monitor" service.
https://issues.apache.org/jira/browse/MIME4J-158
MIME4J-58 - Lenient dealing with headless messages or malformed
header/body separation
https://issues.apache.org/jira/browse/MIME4J-58
MIME4J-153 - Headless inconsistency between MimeTokenStream and MimeStreamParser
https://issues.apache.org/jira/browse/MIME4J-153

Also the folded header stuff you mentioned (MIME4J-141 - MIME4J-146)

> (2) revisit the 'dom' and 'message' packages and try to figure out
> whether 'model' and 'implementation' classes in their present form make
> sense.

+1

> In my option, many of them do not.

They are the result of my limited use case: they work fine in my use
cases (jDKIM + proprietary product).
We need more real use cases to "shape" them, but I trust you (and you
probably have good uses cases too), so I will wait for your review.

Stefano