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 15:40:00 GMT
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 and 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 single 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 rather 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 that 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 in
>> 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. This is
>> something I would avoid changing too often, so it is better to vet it 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.

  Bernd

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


Mime
View raw message