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: 0.6.2 or 0.7 any time soon? was Re: Incorrect line length limitation while parsing headers
Date Tue, 11 Jan 2011 16:13:51 GMT
2011/1/11 Oleg Kalnichevski <olegk@apache.org>:
> On Tue, 2011-01-11 at 15:18 +0100, Stefano Bagnara wrote:
>> 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
>>
>
> Stefano, for the love of God Almighty, what else am I supposed to do?

I don't get what I said to upset you. I'm sorry if you thought I'm on
the way. I keep repeating you just commit your changes, just do
whatever you want on svn and I will be happy. You don't commit
anything so I try discussing. I don't know what you prefer me to do.
I'm just trying to understand how to evolve mime4j.

> I
> pointed out a number of times those things that do not seem to make any
> sense what so ever, like HeaderImpl extending Header, which is a
> CONCRETE class, or abstract Multipart where the only abstract aspects
> are preamble / epilogue related methods.
>
> OK. I will create a copy of mime4j on github and make _minimal_ changes
> to your code just to resolve the most glaring WTFs in the API and
> present it for review. Simply listing things that I disagree with does
> not seem to bring us anywhere anymore.

Why can't you simply work on trunk or on a branch here in our svn? I
think I encouraged you multiple times to simply do this, I don't
really understand why you aswer me like I'm trying to stop you.
My preference is for you to use trunk. We use CTR, so go ahead and I
hope you will be happy if I review what you do.

You are a committer, so we already trust you, so you should no fear
working in trunk. I do this when I have ideas and I expect others to
simply do the same. If what I committed in trunk is blocking evolution
then just revert it, otherwise make your changes: whatever you feel
appropriate.

We will ask questions when we need answers :-)

Stefano

PS: if something I said/did makes you angry just explain me please. I
hope this is just something related to "translation" and the fact we
don't speak the same language natively.

Mime
View raw message