james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann" <bernd.fonderm...@googlemail.com>
Subject Re: [mime4j] what else need to be done (Was: Benchmark of 0.3 vs 0.4)
Date Tue, 05 Aug 2008 17:16:58 GMT
On Tue, Aug 5, 2008 at 18:52, Stefano Bagnara <apache@bago.org> wrote:
> Bernd Fondermann ha scritto:
>> On Tue, Aug 5, 2008 at 18:07, Stefano Bagnara <apache@bago.org> wrote:
>>> Bernd Fondermann ha scritto:
>>>> On Tue, Aug 5, 2008 at 13:41, Niklas Therning <niklas@trillian.se>
>>>> wrote:
>>>>> Stefano Bagnara wrote:
>>>>>> Niklas Therning ha scritto:
>>>>>>> Oleg Kalnichevski wrote:
>>>>>>>> Stefano Bagnara wrote:
>>>>>>>>> Robert Burrell Donkin ha scritto:
>>>>>>>>>> what else needs to be done before we can ship?
>>>>>>>>> I'm looking here:
>>>>>>>>> https://issues.apache.org/jira/browse/MIME4J?report=com.atlassian.jira.plugin.system.project:roadmap-panel
>>>>>>>>> I see 4 issues open for the 0.4 release:
>>>>>>>>> MIME4J-57 Add a max limit to header length for parsing.
>>>>>>>>> https://issues.apache.org/jira/browse/MIME4J-57
>>>>>>>>> - this seems critical because it may results in OOM/DoS,
but we had
>>>>>>>>> this in past too, so could even be moved to 0.5.
>>>>>>>>> MIME4J-69 Decoding/encoding is not coherent between headers
>>>>>>>>> body
>>>>>>>>> https://issues.apache.org/jira/browse/MIME4J-69
>>>>>>>>> - this probably is too complicate to delay a release
and I don't
>>>>>>>>> have
>>>>>>>>> the evergy to discuss how it should be correctly solved,
now. So if
>>>>>>>>> no one
>>>>>>>>> plan to work on it soon, it should be moved to 0.5.
>>>>>>>>> MIME4J-51 Remove cyclic dependencies and provide better
>>>>>>>>> organization
>>>>>>>>> of
>>>>>>>>> the source tree.
>>>>>>>>> https://issues.apache.org/jira/browse/MIME4J-51
>>>>>>>>> - I applied my proposed patch. There are concerns from
you and
>>>>>>>>> Bernd
>>>>>>>>>  1) remove also the util package.
>>>>>>>>>  2) add a package documentation with examples and "parser"
>>>>>>>>> references.
>>>>>>>>> I personally don't care of #1, and if needed I can work
on #2 but
>>>>>>>>> without examples, simply adding a package.html with one
>>>>>>>>> sentence:
>>>>>>>>> "the main classes for the pull and SAX parser are in
the parser
>>>>>>>>> package."
>>>>>>>>> MIME4J-27 [JW#7] Limitations Support
>>>>>>>>> https://issues.apache.org/jira/browse/MIME4J-27
>>>>>>>>> - No answers from Jochen to your question in a month.
maybe it
>>>>>>>>> should
>>>>>>>>> be moved to 0.5.
>>>>>>>>> Once the 4 issues above have been solved (or postponed)
we need a
>>>>>>>>> release manager.
>>>>>>>>> Nothing else I can remember now.
>>>>>>>> Stefano,
>>>>>>>> None of these issues seems severe enough to block the 0.4
release. I
>>>>>>>> would very much appreciate if the 0.4 release could happen
>>>>>>>> sooner
>>>>>>>> than later. It would be very unfortunate if we had to release
>>>>>>>> HttpClient
>>>>>>>> 4.0-beta1 without the HttpMime module.
>>>>>>>> Oleg
>>>>>>> I agree with Oleg. IMO these issues can be moved to 0.5.
>>>>>>> /Niklas
>>>>>> Just to make it clear that I agree with you two, too. I simply dumped
>>>>>> the
>>>>>> JIRA status and told that I had nothing against moving every open
>>>>>> issue
>>>>>> to
>>>>>> 0.5. So, if no one object on this we now miss only the volunteer
>>>>>> will
>>>>>> act as the release manager.
>>>>> Ok, great. I have no idea of what it takes to do a release I'm afraid.
>>>>> Someone else?
>>>>>> After your benchmark I applied the package refactoring I proposed
>>>>>> MIME4J-51, so I'd like you and Oleg to try updating your client code
>>>>>> to
>>>>>> see
>>>>>> how many changes are needed and if the new structure make sense.
>>>>>> is
>>>>>> something I would avoid changing too often, so it is better to vet
>>>>>> now
>>>>>> before we write it in the stone with a release.
>>>>> I'm afraid I have missed the whole "review packaging" discussion, I
>>>>> hope
>>>>> I'm
>>>>> not too late. :) I'd prefer to have MimeStreamParser and
>>>>> MimeTokenStream
>>>>> in
>>>>> the root package if possible. That would be the most natural thing I
>>>>> think
>>>>> since those are by far the most central classes. I also think
>>>>> ContentHandler
>>>>> and AbstractContentHandler could go in the root package. With these
>>>>> changes
>>>>> the upgrade effort for me would be close to none since what we use is
>>>>> probably only MimeStreamParser, ContentHandler and BodyDescriptor. I
>>>>> understand that this would introduce some cycles but I still think that
>>>>> it
>>>>> would make Mime4j a lot easier to use for the end user. I'd rather have
>>>>> some
>>>>> cyclic dependencies if it makes the whole thing easier to understand.
>>>> +1
>>>> Analysing package dependency statistics and correcting most cyclic
>>>> dependencies is good and very helpful. In my opinion, going as far as
>>>> putting up a zero-cycles-policy makes more user-friendly and pragmatic
>>>> solutions like the proposed one impossible. I am repeating myself by
>>>> saying that exposing the central classes in the root package is by far
>>>> the most user friendly.
>>> Niklas, Bernd, please can you make a concrete list of changes you propose
>>> (against current trunk or against the tree before my change) if this is
>>> not
>>> one of the 4 solutions I listed in a recent answer to this thread so that
>>> we
>>> can add a 5th solution to this issue and we can cast our preferences and
>>> see
>>> where the consensus build?
>>> I happen to share only the concern that this change require updates for
>>> old
>>> version users. I don't shared the "user-friendly" and "pragmatic"
>>> concerns.
>>> IMHO a parser package is much more user-friendly and pragmatic than
>>> having
>>> 20 classes in the main package even if I ignore the cycles issue. So it
>>> is
>>> matter of opinions, we should simply poll to see where the majority is.
>> I think Niklas could not have been more concrete by saying that...
>> "I'd prefer to have MimeStreamParser and MimeTokenStream in the root
>> package if possible. That would be the most natural thing I think
>> since those are by far the most central classes. I also think
>> ContentHandler and AbstractContentHandler could go in the root
>> package."
> So the concrete proposal is that we move the 4 classes to the main package?

OMG, I can't believe this discussion can be made even more
complicated. Sometimes writing less is more.
The proposal is to have both central classes, MimeStreamParser and
MimeTokenStream, to the root package.
Optionally, ContentHandler and AbstractContentHandler could go into
the root package.

> The same thing could be accomplished with inverting code and parser, so
> until he will reply imho it was not obvious that what he proposed was moving
> the 4 classes and was fine with it.

To me that became clear from the context.

> The 4 classes and no other class?

He doesn't care for the other classes and I don't either, because
users don't need them for starters. They could even be relocated to
org.apache.mime4j.noncyclic.* or whatever others like.

>> If these are the only classes in root, that's fine with me and that's
>> the proposed change, as I understand it.
>> What's still unclear about it?
> Not sure I fully have it clear, sorry: what about the current 4 classes we
> have in the main package?

I don't care (primarily) and am ready to accept other's preferences here.

> Furthermore: what is the advantage of the new structure if we don't solve
> the MIME4J-51 issue?
> *If*, and I'd like to test this too, the majority think that cyclic
> dependency is not an issue then why should we move classes around at all?

Because classes should be relocated to proper packages.

> IMHO the change itself is an issue for anyone upgrading, so if we don't
> improve something (e.g: remove cycles) it does not worth applying the patch
> at all.

+1. I am counting moving classes to proper packages as an improvement.

> So, before running a poll, I'd like to understand exactly what are the
> proposed options.

A poll will not neccessarily make anything more clear I am afraid.

> IMHO this one (use the new structure but move some class from parser to
> main) is the worst of the 5 analyzed, but I won't veto it, so if this is
> what the majority wants, I'm fine with it.

I don't think that Apache is about majority decisions in the first
place. Majority decisions (votes) are often not including minority
opinions, while finding consensus is about taking every opinion into
acount (known as 'compromising'). If that doesn't work, votes come
into play. (Disclaimer: The readers notion about 'The Apache Way' may


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message