You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stefano Bagnara <ap...@bago.org> on 2008/08/04 18:55:35 UTC
[mime4j] what else need to be done (Was: Benchmark of 0.3 vs 0.4)
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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] what else need to be done (Was: Benchmark of 0.3 vs
0.4)
Posted by Stefano Bagnara <ap...@bago.org>.
Niklas Therning ha scritto:
> Stefano Bagnara wrote:
>> 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.
Ok, please let's discuss about this with the needed calm and timings. If
we find a release manager before we are done with this we can release
what we had just before MIME4J-51, so that we don't change packaging
multiple times.
The core goal of the refactoring was to remove circular/cyclic
dependencies for mime4j packages.
The idea behind moving the parser stuff to "parser" was that mime4j now
supports also writing mime stuff and will probably support mime DOM
handling even without any parsing, so parsing is only one of the aspects
of the library. Furtheremore we can't put classes from parser and
classes from the main package in the same package because this would
reintroduce cycles.
I say we "can't" but I simply think that if we refactor packages this is
a MUST, otherwise it doesn't worth to move stuff around and simply
should vote down MIME4J-51.
In my first proposal we had the parser classes in the main package and
the main package classes in the core package. Robert and I preferred to
invert them, Bernd was for keeping the old structure. No one else
commented so I took the "2 vs 1" as a preference.
IMHO we can invert the 2 packages very easily, we just need an agreement.
Please note that if we move mime4j.parser.* to mime4j and mime4j.* to
mime4j.core you will have anyway to update your code because 4 classes
you import (or at least MimeException and BodyDescriptor) will be moved
to core.
Unfortunately I don't see a solution [1] for leaving the current client
code unchanged and remove cyclic dependencies in packages. I wouldn't
like (this does not mean I would veto this, simply that I don't like it)
to use the current structure and simply move parser.* to the main
package because this would mean loosing my original goal.
In case of James-server we also was using MaximalBodyDescriptor that has
been moved to descriptor package.
The idea is that a repackaging is needed to improve self-documentation
of the code structure and that repackaging usually involve client code
updates. if we want to do that we have to do as soon as possible because
this is not something to do in an 1.0 release.
In order to summarize we can:
1) vote down MIME4J-51 and revert the code change.
2) keep that in trunk for a future release and try to release r680989
(and reapply r682373 and r682374)
3) move mime4j.* to mime4j.core.* and mime4j.parser.* to mime4j.*
4) leave everything as is in trunk.
5) ... any other concrete suggestion is welcome, I don't have more.
My current preference is:
#4 +1 preferred
#3 +0
#2 -0
#1 -0 hope this is not the case as I spent a lot of time refactoring
already twice the codebase for the proposal and for the real application
after I thought we had an agreement, but shit happens, and I won't vote
down a release for this.
Stefano
[1] well, a solution exists: put *everything* (83 classes) in a single
package. but this is not acceptable for me.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] release preparation (packages / MIME4J-51)
Posted by Bernd Fondermann <be...@googlemail.com>.
On Wed, Aug 13, 2008 at 12:40, Stefano Bagnara <ap...@bago.org> wrote:
> The main concern remain from Bernd: are you happy with the javadoc
...it is more my opinion than a concern...
> solution (overview.html) and the current structure?
> http://hudson.zones.apache.org/hudson/job/mime4j-trunk/ws/trunk/target/site/apidocs/index.html
+1, that's ok. Although the link doesn't work for me since I don't
have a login for Hudson yet. But thank god it's open source ;-)
It would be nice to have MimeTokenStream also mentioned, but I guess I
should volunteer to add that. (see note above :-))
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] release preparation (packages / MIME4J-51)
Posted by Stefano Bagnara <ap...@bago.org>.
Stefano Bagnara ha scritto:
> Oleg Kalnichevski ha scritto:
>> On Wed, 2008-08-13 at 20:45 +0100, Robert Burrell Donkin wrote:
>>> On Wed, Aug 13, 2008 at 6:10 PM, Oleg Kalnichevski <ol...@apache.org>
>>> wrote:
>>>> On Wed, 2008-08-13 at 12:40 +0200, Stefano Bagnara wrote:
>>>>> About the repackaging (MIME4J-51) I think we almost have an agreement,
>>>>> so I'd like to push this a little to understand if we can complete
>>>>> this
>>>>> and avoid reverting this or releasing something in progress.
>>>>>
>>>>> AFAICT the only pending issue is the "stream" package.
>>>>>
>>>>> Niklas commented:
>>>>>> * Rename the stream package io. MimeTokenStream is a stream too. It's
>>>>>> a bit confusing to me that it isn't in the stream package.
>>>>> I replied:
>>>>>> I'm fine with "io" but maybe a better option would be
>>>>>> streamfilters"/"inputstreams"/"inputfilters"/"filterinputstreams"/"filteris"
>>>>>> so to make it more descriptive. Opinions?
>>>>> My current preference is "streamfilter" (more descriptive than "io"
>>>>> but
>>>>> shorter than "filterinputstreams"), but I'm happy with any name.
>>>>>
>>>> +1 to renaming 'stream' as 'io'. We may end up having classes that are
>>>> related to IO but are not streams. IO sounds generic enough yet
>>>> descriptive.
>>> +1
>>>
>>
>> Folks
>>
>> As far as I can tell no one objects the idea. If I hear no complaints,
>> I'll go ahead and rename the package and close MIME4J-51 tomorrow.
>
> +1
I was on mime4j (for the LICENSE issue) now, so I simply stole this job
from you and did it :-)
Release time.... !!!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] release preparation (packages / MIME4J-51)
Posted by Stefano Bagnara <ap...@bago.org>.
Oleg Kalnichevski ha scritto:
> On Wed, 2008-08-13 at 20:45 +0100, Robert Burrell Donkin wrote:
>> On Wed, Aug 13, 2008 at 6:10 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
>>> On Wed, 2008-08-13 at 12:40 +0200, Stefano Bagnara wrote:
>>>> About the repackaging (MIME4J-51) I think we almost have an agreement,
>>>> so I'd like to push this a little to understand if we can complete this
>>>> and avoid reverting this or releasing something in progress.
>>>>
>>>> AFAICT the only pending issue is the "stream" package.
>>>>
>>>> Niklas commented:
>>>>> * Rename the stream package io. MimeTokenStream is a stream too. It's
>>>>> a bit confusing to me that it isn't in the stream package.
>>>> I replied:
>>>>> I'm fine with "io" but maybe a better option would be
>>>>> streamfilters"/"inputstreams"/"inputfilters"/"filterinputstreams"/"filteris" so to make it more descriptive. Opinions?
>>>> My current preference is "streamfilter" (more descriptive than "io" but
>>>> shorter than "filterinputstreams"), but I'm happy with any name.
>>>>
>>> +1 to renaming 'stream' as 'io'. We may end up having classes that are
>>> related to IO but are not streams. IO sounds generic enough yet
>>> descriptive.
>> +1
>>
>
> Folks
>
> As far as I can tell no one objects the idea. If I hear no complaints,
> I'll go ahead and rename the package and close MIME4J-51 tomorrow.
+1
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] release preparation (packages / MIME4J-51)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2008-08-13 at 20:45 +0100, Robert Burrell Donkin wrote:
> On Wed, Aug 13, 2008 at 6:10 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
> > On Wed, 2008-08-13 at 12:40 +0200, Stefano Bagnara wrote:
> >> About the repackaging (MIME4J-51) I think we almost have an agreement,
> >> so I'd like to push this a little to understand if we can complete this
> >> and avoid reverting this or releasing something in progress.
> >>
> >> AFAICT the only pending issue is the "stream" package.
> >>
> >> Niklas commented:
> >> > * Rename the stream package io. MimeTokenStream is a stream too. It's
> >> > a bit confusing to me that it isn't in the stream package.
> >>
> >> I replied:
> >> > I'm fine with "io" but maybe a better option would be
> >> > streamfilters"/"inputstreams"/"inputfilters"/"filterinputstreams"/"filteris" so to make it more descriptive. Opinions?
> >>
> >> My current preference is "streamfilter" (more descriptive than "io" but
> >> shorter than "filterinputstreams"), but I'm happy with any name.
> >>
> >
> > +1 to renaming 'stream' as 'io'. We may end up having classes that are
> > related to IO but are not streams. IO sounds generic enough yet
> > descriptive.
>
> +1
>
Folks
As far as I can tell no one objects the idea. If I hear no complaints,
I'll go ahead and rename the package and close MIME4J-51 tomorrow.
Oleg
> >> If I understand correctly there is consensus about the parser package.
> >> The main concern remain from Bernd: are you happy with the javadoc
> >> solution (overview.html) and the current structure?
> >> http://hudson.zones.apache.org/hudson/job/mime4j-trunk/ws/trunk/target/site/apidocs/index.html
> >>
> >>
> >> http://people.apache.org/~bago/mime4j/mime4j-51/graph-mime4j-package.gif
> >>
> >> Oleg, I hope this summary let you understand what is the current status
> >> of MIME4J-51 and the consensus around it.
> >>
> >> I leave to you the decision about releasing without the refactoring
> >> (revert MIME4J-51), release "as is", or see the answers about the
> >> "stream" package and "complete it" before releasing.
> >>
> >
> > In the worst case I see no harm in releasing things as they stand and
> > revisiting MIME4J-51 during the 0.5 development.
>
> +1
>
> release early, release often ;-)
>
> i see no reason why we can't push ahead quickly with a 0.5 once 0.4
> has been released. IMHO it should be easier to settled some arguments
> when we can use benchmarking.
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] release preparation (packages / MIME4J-51)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Aug 13, 2008 at 6:10 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Wed, 2008-08-13 at 12:40 +0200, Stefano Bagnara wrote:
>> About the repackaging (MIME4J-51) I think we almost have an agreement,
>> so I'd like to push this a little to understand if we can complete this
>> and avoid reverting this or releasing something in progress.
>>
>> AFAICT the only pending issue is the "stream" package.
>>
>> Niklas commented:
>> > * Rename the stream package io. MimeTokenStream is a stream too. It's
>> > a bit confusing to me that it isn't in the stream package.
>>
>> I replied:
>> > I'm fine with "io" but maybe a better option would be
>> > streamfilters"/"inputstreams"/"inputfilters"/"filterinputstreams"/"filteris" so to make it more descriptive. Opinions?
>>
>> My current preference is "streamfilter" (more descriptive than "io" but
>> shorter than "filterinputstreams"), but I'm happy with any name.
>>
>
> +1 to renaming 'stream' as 'io'. We may end up having classes that are
> related to IO but are not streams. IO sounds generic enough yet
> descriptive.
+1
>> If I understand correctly there is consensus about the parser package.
>> The main concern remain from Bernd: are you happy with the javadoc
>> solution (overview.html) and the current structure?
>> http://hudson.zones.apache.org/hudson/job/mime4j-trunk/ws/trunk/target/site/apidocs/index.html
>>
>>
>> http://people.apache.org/~bago/mime4j/mime4j-51/graph-mime4j-package.gif
>>
>> Oleg, I hope this summary let you understand what is the current status
>> of MIME4J-51 and the consensus around it.
>>
>> I leave to you the decision about releasing without the refactoring
>> (revert MIME4J-51), release "as is", or see the answers about the
>> "stream" package and "complete it" before releasing.
>>
>
> In the worst case I see no harm in releasing things as they stand and
> revisiting MIME4J-51 during the 0.5 development.
+1
release early, release often ;-)
i see no reason why we can't push ahead quickly with a 0.5 once 0.4
has been released. IMHO it should be easier to settled some arguments
when we can use benchmarking.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] release preparation (packages / MIME4J-51)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2008-08-13 at 12:40 +0200, Stefano Bagnara wrote:
> About the repackaging (MIME4J-51) I think we almost have an agreement,
> so I'd like to push this a little to understand if we can complete this
> and avoid reverting this or releasing something in progress.
>
> AFAICT the only pending issue is the "stream" package.
>
> Niklas commented:
> > * Rename the stream package io. MimeTokenStream is a stream too. It's
> > a bit confusing to me that it isn't in the stream package.
>
> I replied:
> > I'm fine with "io" but maybe a better option would be
> > streamfilters"/"inputstreams"/"inputfilters"/"filterinputstreams"/"filteris" so to make it more descriptive. Opinions?
>
> My current preference is "streamfilter" (more descriptive than "io" but
> shorter than "filterinputstreams"), but I'm happy with any name.
>
+1 to renaming 'stream' as 'io'. We may end up having classes that are
related to IO but are not streams. IO sounds generic enough yet
descriptive.
> If I understand correctly there is consensus about the parser package.
> The main concern remain from Bernd: are you happy with the javadoc
> solution (overview.html) and the current structure?
> http://hudson.zones.apache.org/hudson/job/mime4j-trunk/ws/trunk/target/site/apidocs/index.html
>
>
> http://people.apache.org/~bago/mime4j/mime4j-51/graph-mime4j-package.gif
>
> Oleg, I hope this summary let you understand what is the current status
> of MIME4J-51 and the consensus around it.
>
> I leave to you the decision about releasing without the refactoring
> (revert MIME4J-51), release "as is", or see the answers about the
> "stream" package and "complete it" before releasing.
>
In the worst case I see no harm in releasing things as they stand and
revisiting MIME4J-51 during the 0.5 development.
> If you decide anything and need help with action (e.g: revert the code)
> just let me know. If you need help with our "tricky" m2 setup you can
> find me in #james channel @freenode (and many IMs network.. ).
>
Thanks. I appreciate that.
Cheers
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[mime4j] release preparation (packages / MIME4J-51)
Posted by Stefano Bagnara <ap...@bago.org>.
About the repackaging (MIME4J-51) I think we almost have an agreement,
so I'd like to push this a little to understand if we can complete this
and avoid reverting this or releasing something in progress.
AFAICT the only pending issue is the "stream" package.
Niklas commented:
> * Rename the stream package io. MimeTokenStream is a stream too. It's
> a bit confusing to me that it isn't in the stream package.
I replied:
> I'm fine with "io" but maybe a better option would be
> streamfilters"/"inputstreams"/"inputfilters"/"filterinputstreams"/"filteris" so to make it more descriptive. Opinions?
My current preference is "streamfilter" (more descriptive than "io" but
shorter than "filterinputstreams"), but I'm happy with any name.
If I understand correctly there is consensus about the parser package.
The main concern remain from Bernd: are you happy with the javadoc
solution (overview.html) and the current structure?
http://hudson.zones.apache.org/hudson/job/mime4j-trunk/ws/trunk/target/site/apidocs/index.html
http://people.apache.org/~bago/mime4j/mime4j-51/graph-mime4j-package.gif
Oleg, I hope this summary let you understand what is the current status
of MIME4J-51 and the consensus around it.
I leave to you the decision about releasing without the refactoring
(revert MIME4J-51), release "as is", or see the answers about the
"stream" package and "complete it" before releasing.
If you decide anything and need help with action (e.g: revert the code)
just let me know. If you need help with our "tricky" m2 setup you can
find me in #james channel @freenode (and many IMs network.. ).
Here is a tutorial from Norman describing how we released mime4j 0.3:
http://svn.apache.org/repos/asf/james/project/trunk/HOWTO_RELEASE.txt
I just fixed a couple of issues in the generated website (bad refereces
to the apidocs). I saw the "news" page would require some changes but I
don't know what to write. Maybe we can include the release notes text
there once you prepared it.
Here is the current "News and Status" page as built by Hudson:
http://hudson.zones.apache.org/hudson/job/mime4j-trunk/ws/trunk/target/site/status.html
You can also see I added a "Related Projects" menu and linked
"httpmime". Please check it is ok for you and do your changes if you
have preferred land pages.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[mime4j] packages / MIME4J-51 (Was: what else need to be done)
Posted by Stefano Bagnara <ap...@bago.org>.
Niklas Therning ha scritto:
> Stefano Bagnara wrote:
>> Niklas Therning ha scritto:
>>> Stefano Bagnara wrote:
>> [...]
>> Here is an updated summary of what are our current proposed solutions:
>>
>> A) vote down MIME4J-51 and revert the code change.
>> + least surprise
>> + no upgrading effort required
>> * parser is in main package
>> - not good package classification
>> - cyclic dependencies
>>
>> B) move mime4j.* to mime4j.core.* and mime4j.parser.* to mime4j.* (so
>> to bring parser classes in the main package).
>> + remove cyclic dependencies
>> + better packaging
>> * parser is in main package
>> - BodyDescriptor and MimeException are in a different package than
>> before (upgrading issue)
>> - MaximalBodyDescriptor is a different package than before
>> (upgrading issue, at least for james-server)
>>
>> C) leave everything as is in trunk (mime4j-51 applied!).
>> + remove cyclic dependencies
>> + better packaging
>> + better organization to host non parsing related code, too.
>> * parser is in the parser package
>> - most "public" classes are moved around (upgrading issue)
>> - main parser classes are in mime4j.parser instead of main.
>>
>> D) move ContentHandler, AbstractContentHandler, MimeStreamParser,
>> MimeTokenStream from parser to main:
>> + better packaging
>> * parser is in main package
>> - cyclic dependencies: introduce 6 new package cycles:
>> main => parser => descriptor => field.datetime.parser => main
>> main => parser => descriptor => field.mimeversion => main
>> main => parser => descriptor => field.structured => main
>> main => parser => descriptor => field.language => main
>> main => parser => descriptor => main
>> main => parser => mime4j
>> - MaximalBodyDescriptor is in a differet package (upgrading issue)
>> [...]
>> This is what I think should be used as starting point for a POLL
>> unless we find a better agreement, so, before going to a POLL (given
>> that Bernd say we should not use polls), can you tell if #3 would work
>> for you by fixing the "parser centrality" issue but not fixing the
>> "upgrading issue" ?
>
> I'm not following you here. Do you mean "C" when you say #3?
My bad!! The mail refactoring before posting gone wrong! I need explicit
type casting so refactoring can take care of updating my mail
automatically :-P
#3 should have been "B"...
>> The "D" option (your proposal) was not on discussion previously so I
>> can only tell what is my current understanding of what people would
>> support. Where I don't put more names is because I don't yet
>> know/understand their position wrt the given option. Of course this is
>> my personal feeling and while I only do my best to understand people I
>> may be wrong in interpreting ideas, so everyone is welcome to fix my
>> understanding.
>>
>> A. -0 bago
>> B. +0/+1 robert/oleg/bago/bernd.
>> C. +1 bago/robert -0.5 bernd/niklas
>> D. -0.5 bago, +1 niklas
>>
>> If you like "B" I think (based on the above "table" and
>> considerations) we could find consensus there, otherwise I would
>> prefer to go the poll way so we test for real what people think and we
>> don't have to go through my understanding.
>
> I've thought about these options and I think I can actually live
> happily! :) with "C". I understand why you want the parser package and
> after giving this a bit more thought I think it would be a good way of
> organizing the code. We will have to add the package documentation for
> the main package as Bernd suggested.
I added an overview.html file. I thought this is more appropriate than a
package documentation, ATM. It simply have some paragraph from our
website home including a link to the parser/MimeStreamParser and the
message/Message classes.
I'm not so good in english and I don't have the same mime4j knowledge
you may have, so please look at it and make any change you think is
needed :-) (or write them here and I'll take care of the commit)
Here (if last build on hudson is working) you see how the generated
javadocs looks like:
http://hudson.zones.apache.org/hudson/job/mime4j-trunk/ws/trunk/target/site/apidocs/index.html
> I have two requests when it comes to "C":
>
> * move the *Descriptor classes from the main package to the descriptor
> package. It doesn't make sense to have a package named descriptor and
> then having some classes, so closely related to what's inside this
> package, outside of it. AFAICS this doesn't introduce any cycles. Please
> verify this because my JDepend skills are terrible. :)
You mean moving "BodyDescriptor", "ContentDescriptor" and
"MutableBodyDescritor" from main to descriptor, right? This sounds
great, no new cycles and indeed a better "class-tree" to "package"
classification!
I already committed it :-)
Here is the current package tree:
http://people.apache.org/~bago/mime4j/mime4j-51/graph-mime4j-package.gif
> * Rename the stream package io. MimeTokenStream is a stream too. It's a
> bit confusing to me that it isn't in the stream package.
I agree.
I just committed a refactoring to make most of them extensions of
FilterInputStream as they all of them take an inputstream in the
constructor, so maybe streamfilters is the best one... I didn't convert
EOLConvertingInputStream because it introduce one more filter in between
and it's less easy to update, but it is a filter in facts.
I'm fine with "io" but maybe a better option would be
"streamfilters"/"inputstreams"/"inputfilters"/"filterinputstreams"/"filteris"
so to make it more descriptive. Opinions?
In the mean time I also created a message.storage package we discussed
in past so to remove some more utility classes from the util package.
ATM I have no solution (to the concern raised by Bernd and Robert) for
the remaining utils because each of them is used by almost every other
package we have:
http://people.apache.org/~bago/mime4j/mime4j-51/mime4j-utils.gif
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] what else need to be done (Was: Benchmark of 0.3 vs
0.4)
Posted by Niklas Therning <ni...@trillian.se>.
Stefano Bagnara wrote:
> Niklas Therning ha scritto:
>> Stefano Bagnara wrote:
>>> Robert Burrell Donkin ha scritto:
>>>> On Tue, Aug 5, 2008 at 6:16 PM, Bernd Fondermann
>>>> <be...@googlemail.com> wrote:
>>>>> On Tue, Aug 5, 2008 at 18:52, Stefano Bagnara <ap...@bago.org>
>>>>> wrote:
>>>>
>>>> <snip>
>>>>
>>>>>> 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
>>>>> vary.)
>>>>
>>>> i think it's important to let people know about changes like this and
>>>> assemble some kind of rough consensus before embarking. i think
>>>> there's now a consensus that these changes are broadly an improvement
>>>> but that more refinements are possible. let's just apply the proposal
>>>> and then start working on the improvements.
>>>
>>> MIME4J-51 proposal has already been applied, unfortunately what I
>>> thought was consensus a week ago now seems something invented by me ;-)
>>>
>>> My questions to Niklas and Bernd are really to understand if
>>> "refinements" is something that can be done on the refactored tree
>>> or if the consensus is now too far from that and we should better
>>> revert it and start from that.
>>>
>>> I'm scared that people think I'm pushing my proposal or pushing my
>>> cycle dependencies issues when I just want to see something done.
>>>
>>> I hope Niklas will update us soon, without fears or bad feelings wrt
>>> this thread, and I also hope that someone else with better
>>> communications skills can show what's wrong in the way I try to
>>> build consensus.
>>
>> Hi,
>>
>> I certainly understand the merits of trying to reduce cyclic package
>> dependencies, especially for the developers developing the software.
>> My only concern is that zero cyclic dependencies in a library such as
>> Mime4j doesn't necessarily mean that it will be easier to use for the
>> end user.
>
> I think mathematical methods are the only pragmatic method to classify
> classes in packages. Otherwise we speak about personal preferences,
> that's why I'm so used to dependency analysis.
> IMHO a dependency graph and a correct package hierarchy tells much
> more than any documentation.
> I understand this is a matter of personal feeling/style and I don't
> want to convince anyone, nor to be convinced by anyone.
>
>> I definitely think that most of the refactorings you've made are
>> great. My suggestion was only to move the four classes/interfaces I
>> mentioned to the root package. That's all. I've played around with
>> JDepend and if I understand correctly this change results in a single
>> cycle (mime4j <-> parser).
>
> I tried the change and I find 6 cycles, more about this at the end of
> this message.
>
> In my experience either you care of cycles and remove all of them or
> you don't care at all of them. There is no such thing as "reduce the
> cycles". Either the package dependency graph is a tree or it is not a
> tree, there is nothing in the middle.
>
> before-MIME4J-51 the main package contained core classes like
> BodyDescriptor and MimeException used by almost all the code and every
> package and at the same time it contain parser classes that use code
> from every package. If you put them in the same package you introduce
> a lot of cycles, there is no way around or compromise for this.
>
> I understand that some practice is frustrating for people not
> embracing it and that's why I took the proposal way and that's why I
> would happily accept to revert the change (if this will be the
> consensus) and I won't try to convince anyone of my opinions.
>
>> My gut feeling is that this would make it easier for the end user.
>> However, as an active committer I'm not the typical end user myself
>> so my gut feeling could be wrong. I can definitely live with what is
>> in trunk right now. To me it is more important that we release a new
>> version soon. Also, at this stage of the project I think we can
>> afford to (and probably we will) change our minds about the package
>> hierarchy a couple of times more as the code evolves.
>
> I agree on the release: let's not link this issue to the release or
> will make a fast/bad decision for an unrelated goal.
>
> As I'll summarize later we can easily ship a release even today
> including pre refactoring code, we just miss the release manager and
> this is not a matter of solving this issue. We all agree on this, so
> no need to mix the release issue with the repackaging+cycles issues.
>
> No one vetoed any of the proposed solution, so, in fact we are
> discussing to find the best solution, not to find an acceptable
> solution, and this is really good. Everyone can live whatever we
> decide, so let's collect preferences and go with what makes more
> people not only living, but living more happy! :-)
>
>> I don't think there is anything wrong with your communication skills.
>> I'm impressed that you are investing so much of your personal time in
>> trying to make Mime4j a better piece of software. Don't stop doing
>> that! :) The reason why I didn't raise my concerns earlier is that I
>> haven't had the time to catch up until now (I just come back from
>> vacation).
>
> Thank you!
>
> Now I better understand your point and I see we have different
> (somehow diverging) opinions about this.
> Unfortunately for me (and trying to find a consensus) this is
> different from Bernd interpretation, so I'll ask you some more
> questions if you don't mind.
>
> Here is an updated summary of what are our current proposed solutions:
>
> A) vote down MIME4J-51 and revert the code change.
> + least surprise
> + no upgrading effort required
> * parser is in main package
> - not good package classification
> - cyclic dependencies
>
> B) move mime4j.* to mime4j.core.* and mime4j.parser.* to mime4j.* (so
> to bring parser classes in the main package).
> + remove cyclic dependencies
> + better packaging
> * parser is in main package
> - BodyDescriptor and MimeException are in a different package than
> before (upgrading issue)
> - MaximalBodyDescriptor is a different package than before
> (upgrading issue, at least for james-server)
>
> C) leave everything as is in trunk (mime4j-51 applied!).
> + remove cyclic dependencies
> + better packaging
> + better organization to host non parsing related code, too.
> * parser is in the parser package
> - most "public" classes are moved around (upgrading issue)
> - main parser classes are in mime4j.parser instead of main.
>
> D) move ContentHandler, AbstractContentHandler, MimeStreamParser,
> MimeTokenStream from parser to main:
> + better packaging
> * parser is in main package
> - cyclic dependencies: introduce 6 new package cycles:
> main => parser => descriptor => field.datetime.parser => main
> main => parser => descriptor => field.mimeversion => main
> main => parser => descriptor => field.structured => main
> main => parser => descriptor => field.language => main
> main => parser => descriptor => main
> main => parser => mime4j
> - MaximalBodyDescriptor is in a differet package (upgrading issue)
>
> There is another option I removed:
> X) keep that in trunk for a future release and try to release r680989
> (and reapply r682373 and r682374)
> * this is almost the same of "A" in the short, but already define
> a roadmap for the future (could be "B"/"C"/"D").
> I think that everyone agree that the release has the priority on
> everything, so this is a non-option. Regardless from what we or we
> will agree we can release r680989 and reapply r682373 and r682374 at
> any time.
>
> This is what I think should be used as starting point for a POLL
> unless we find a better agreement, so, before going to a POLL (given
> that Bernd say we should not use polls), can you tell if #3 would work
> for you by fixing the "parser centrality" issue but not fixing the
> "upgrading issue" ?
I'm not following you here. Do you mean "C" when you say #3?
>
> The "D" option (your proposal) was not on discussion previously so I
> can only tell what is my current understanding of what people would
> support. Where I don't put more names is because I don't yet
> know/understand their position wrt the given option. Of course this is
> my personal feeling and while I only do my best to understand people I
> may be wrong in interpreting ideas, so everyone is welcome to fix my
> understanding.
>
> A. -0 bago
> B. +0/+1 robert/oleg/bago/bernd.
> C. +1 bago/robert -0.5 bernd/niklas
> D. -0.5 bago, +1 niklas
>
> If you like "B" I think (based on the above "table" and
> considerations) we could find consensus there, otherwise I would
> prefer to go the poll way so we test for real what people think and we
> don't have to go through my understanding.
I've thought about these options and I think I can actually live
happily! :) with "C". I understand why you want the parser package and
after giving this a bit more thought I think it would be a good way of
organizing the code. We will have to add the package documentation for
the main package as Bernd suggested. I have two requests when it comes
to "C":
* move the *Descriptor classes from the main package to the descriptor
package. It doesn't make sense to have a package named descriptor and
then having some classes, so closely related to what's inside this
package, outside of it. AFAICS this doesn't introduce any cycles. Please
verify this because my JDepend skills are terrible. :)
* Rename the stream package io. MimeTokenStream is a stream too. It's a
bit confusing to me that it isn't in the stream package.
/Niklas
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] what else need to be done (Was: Benchmark of 0.3 vs
0.4)
Posted by Stefano Bagnara <ap...@bago.org>.
Niklas Therning ha scritto:
> Stefano Bagnara wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Tue, Aug 5, 2008 at 6:16 PM, Bernd Fondermann
>>> <be...@googlemail.com> wrote:
>>>> On Tue, Aug 5, 2008 at 18:52, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>> <snip>
>>>
>>>>> 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
>>>> vary.)
>>>
>>> i think it's important to let people know about changes like this and
>>> assemble some kind of rough consensus before embarking. i think
>>> there's now a consensus that these changes are broadly an improvement
>>> but that more refinements are possible. let's just apply the proposal
>>> and then start working on the improvements.
>>
>> MIME4J-51 proposal has already been applied, unfortunately what I
>> thought was consensus a week ago now seems something invented by me ;-)
>>
>> My questions to Niklas and Bernd are really to understand if
>> "refinements" is something that can be done on the refactored tree or
>> if the consensus is now too far from that and we should better revert
>> it and start from that.
>>
>> I'm scared that people think I'm pushing my proposal or pushing my
>> cycle dependencies issues when I just want to see something done.
>>
>> I hope Niklas will update us soon, without fears or bad feelings wrt
>> this thread, and I also hope that someone else with better
>> communications skills can show what's wrong in the way I try to build
>> consensus.
>
> Hi,
>
> I certainly understand the merits of trying to reduce cyclic package
> dependencies, especially for the developers developing the software. My
> only concern is that zero cyclic dependencies in a library such as
> Mime4j doesn't necessarily mean that it will be easier to use for the
> end user.
I think mathematical methods are the only pragmatic method to classify
classes in packages. Otherwise we speak about personal preferences,
that's why I'm so used to dependency analysis.
IMHO a dependency graph and a correct package hierarchy tells much more
than any documentation.
I understand this is a matter of personal feeling/style and I don't want
to convince anyone, nor to be convinced by anyone.
> I definitely think that most of the refactorings you've made are great.
> My suggestion was only to move the four classes/interfaces I mentioned
> to the root package. That's all. I've played around with JDepend and if
> I understand correctly this change results in a single cycle (mime4j <->
> parser).
I tried the change and I find 6 cycles, more about this at the end of
this message.
In my experience either you care of cycles and remove all of them or you
don't care at all of them. There is no such thing as "reduce the
cycles". Either the package dependency graph is a tree or it is not a
tree, there is nothing in the middle.
before-MIME4J-51 the main package contained core classes like
BodyDescriptor and MimeException used by almost all the code and every
package and at the same time it contain parser classes that use code
from every package. If you put them in the same package you introduce a
lot of cycles, there is no way around or compromise for this.
I understand that some practice is frustrating for people not embracing
it and that's why I took the proposal way and that's why I would happily
accept to revert the change (if this will be the consensus) and I won't
try to convince anyone of my opinions.
> My gut feeling is that this would make it easier for the end
> user. However, as an active committer I'm not the typical end user
> myself so my gut feeling could be wrong. I can definitely live with what
> is in trunk right now. To me it is more important that we release a new
> version soon. Also, at this stage of the project I think we can afford
> to (and probably we will) change our minds about the package hierarchy a
> couple of times more as the code evolves.
I agree on the release: let's not link this issue to the release or will
make a fast/bad decision for an unrelated goal.
As I'll summarize later we can easily ship a release even today
including pre refactoring code, we just miss the release manager and
this is not a matter of solving this issue. We all agree on this, so no
need to mix the release issue with the repackaging+cycles issues.
No one vetoed any of the proposed solution, so, in fact we are
discussing to find the best solution, not to find an acceptable
solution, and this is really good. Everyone can live whatever we decide,
so let's collect preferences and go with what makes more people not only
living, but living more happy! :-)
> I don't think there is anything wrong with your communication skills.
> I'm impressed that you are investing so much of your personal time in
> trying to make Mime4j a better piece of software. Don't stop doing that!
> :) The reason why I didn't raise my concerns earlier is that I haven't
> had the time to catch up until now (I just come back from vacation).
Thank you!
Now I better understand your point and I see we have different (somehow
diverging) opinions about this.
Unfortunately for me (and trying to find a consensus) this is different
from Bernd interpretation, so I'll ask you some more questions if you
don't mind.
Here is an updated summary of what are our current proposed solutions:
A) vote down MIME4J-51 and revert the code change.
+ least surprise
+ no upgrading effort required
* parser is in main package
- not good package classification
- cyclic dependencies
B) move mime4j.* to mime4j.core.* and mime4j.parser.* to mime4j.* (so to
bring parser classes in the main package).
+ remove cyclic dependencies
+ better packaging
* parser is in main package
- BodyDescriptor and MimeException are in a different package than
before (upgrading issue)
- MaximalBodyDescriptor is a different package than before
(upgrading issue, at least for james-server)
C) leave everything as is in trunk (mime4j-51 applied!).
+ remove cyclic dependencies
+ better packaging
+ better organization to host non parsing related code, too.
* parser is in the parser package
- most "public" classes are moved around (upgrading issue)
- main parser classes are in mime4j.parser instead of main.
D) move ContentHandler, AbstractContentHandler, MimeStreamParser,
MimeTokenStream from parser to main:
+ better packaging
* parser is in main package
- cyclic dependencies: introduce 6 new package cycles:
main => parser => descriptor => field.datetime.parser => main
main => parser => descriptor => field.mimeversion => main
main => parser => descriptor => field.structured => main
main => parser => descriptor => field.language => main
main => parser => descriptor => main
main => parser => mime4j
- MaximalBodyDescriptor is in a differet package (upgrading issue)
There is another option I removed:
X) keep that in trunk for a future release and try to release r680989
(and reapply r682373 and r682374)
* this is almost the same of "A" in the short, but already define
a roadmap for the future (could be "B"/"C"/"D").
I think that everyone agree that the release has the priority on
everything, so this is a non-option. Regardless from what we or we will
agree we can release r680989 and reapply r682373 and r682374 at any time.
This is what I think should be used as starting point for a POLL unless
we find a better agreement, so, before going to a POLL (given that Bernd
say we should not use polls), can you tell if #3 would work for you by
fixing the "parser centrality" issue but not fixing the "upgrading issue" ?
The "D" option (your proposal) was not on discussion previously so I can
only tell what is my current understanding of what people would support.
Where I don't put more names is because I don't yet know/understand
their position wrt the given option. Of course this is my personal
feeling and while I only do my best to understand people I may be wrong
in interpreting ideas, so everyone is welcome to fix my understanding.
A. -0 bago
B. +0/+1 robert/oleg/bago/bernd.
C. +1 bago/robert -0.5 bernd/niklas
D. -0.5 bago, +1 niklas
If you like "B" I think (based on the above "table" and considerations)
we could find consensus there, otherwise I would prefer to go the poll
way so we test for real what people think and we don't have to go
through my understanding.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] what else need to be done (Was: Benchmark of 0.3 vs
0.4)
Posted by Niklas Therning <ni...@trillian.se>.
Stefano Bagnara wrote:
> Robert Burrell Donkin ha scritto:
>> On Tue, Aug 5, 2008 at 6:16 PM, Bernd Fondermann
>> <be...@googlemail.com> wrote:
>>> On Tue, Aug 5, 2008 at 18:52, Stefano Bagnara <ap...@bago.org> wrote:
>>
>> <snip>
>>
>>>> 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
>>> vary.)
>>
>> i think it's important to let people know about changes like this and
>> assemble some kind of rough consensus before embarking. i think
>> there's now a consensus that these changes are broadly an improvement
>> but that more refinements are possible. let's just apply the proposal
>> and then start working on the improvements.
>
> MIME4J-51 proposal has already been applied, unfortunately what I
> thought was consensus a week ago now seems something invented by me ;-)
>
> My questions to Niklas and Bernd are really to understand if
> "refinements" is something that can be done on the refactored tree or
> if the consensus is now too far from that and we should better revert
> it and start from that.
>
> I'm scared that people think I'm pushing my proposal or pushing my
> cycle dependencies issues when I just want to see something done.
>
> I hope Niklas will update us soon, without fears or bad feelings wrt
> this thread, and I also hope that someone else with better
> communications skills can show what's wrong in the way I try to build
> consensus.
Hi,
I certainly understand the merits of trying to reduce cyclic package
dependencies, especially for the developers developing the software. My
only concern is that zero cyclic dependencies in a library such as
Mime4j doesn't necessarily mean that it will be easier to use for the
end user.
I definitely think that most of the refactorings you've made are great.
My suggestion was only to move the four classes/interfaces I mentioned
to the root package. That's all. I've played around with JDepend and if
I understand correctly this change results in a single cycle (mime4j <->
parser). My gut feeling is that this would make it easier for the end
user. However, as an active committer I'm not the typical end user
myself so my gut feeling could be wrong. I can definitely live with what
is in trunk right now. To me it is more important that we release a new
version soon. Also, at this stage of the project I think we can afford
to (and probably we will) change our minds about the package hierarchy a
couple of times more as the code evolves.
I don't think there is anything wrong with your communication skills.
I'm impressed that you are investing so much of your personal time in
trying to make Mime4j a better piece of software. Don't stop doing that!
:) The reason why I didn't raise my concerns earlier is that I haven't
had the time to catch up until now (I just come back from vacation).
/Niklas
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] what else need to be done (Was: Benchmark of 0.3 vs
0.4)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Tue, Aug 5, 2008 at 6:16 PM, Bernd Fondermann
> <be...@googlemail.com> wrote:
>> On Tue, Aug 5, 2008 at 18:52, Stefano Bagnara <ap...@bago.org> wrote:
>
> <snip>
>
>>> 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
>> vary.)
>
> i think it's important to let people know about changes like this and
> assemble some kind of rough consensus before embarking. i think
> there's now a consensus that these changes are broadly an improvement
> but that more refinements are possible. let's just apply the proposal
> and then start working on the improvements.
MIME4J-51 proposal has already been applied, unfortunately what I
thought was consensus a week ago now seems something invented by me ;-)
My questions to Niklas and Bernd are really to understand if
"refinements" is something that can be done on the refactored tree or if
the consensus is now too far from that and we should better revert it
and start from that.
I'm scared that people think I'm pushing my proposal or pushing my cycle
dependencies issues when I just want to see something done.
I hope Niklas will update us soon, without fears or bad feelings wrt
this thread, and I also hope that someone else with better
communications skills can show what's wrong in the way I try to build
consensus.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] what else need to be done (Was: Benchmark of 0.3 vs 0.4)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, Aug 5, 2008 at 6:16 PM, Bernd Fondermann
<be...@googlemail.com> wrote:
> On Tue, Aug 5, 2008 at 18:52, Stefano Bagnara <ap...@bago.org> wrote:
<snip>
>> 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
> vary.)
i think it's important to let people know about changes like this and
assemble some kind of rough consensus before embarking. i think
there's now a consensus that these changes are broadly an improvement
but that more refinements are possible. let's just apply the proposal
and then start working on the improvements.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] what else need to be done (Was: Benchmark of 0.3 vs 0.4)
Posted by Bernd Fondermann <be...@googlemail.com>.
On Tue, Aug 5, 2008 at 18:52, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann ha scritto:
>>
>> On Tue, Aug 5, 2008 at 18:07, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>> Bernd Fondermann ha scritto:
>>>>
>>>> On Tue, Aug 5, 2008 at 13:41, Niklas Therning <ni...@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.
>>>
>>> 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
vary.)
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] what else need to be done (Was: Benchmark of 0.3 vs
0.4)
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann ha scritto:
> On Tue, Aug 5, 2008 at 18:07, Stefano Bagnara <ap...@bago.org> wrote:
>> Bernd Fondermann ha scritto:
>>> On Tue, Aug 5, 2008 at 13:41, Niklas Therning <ni...@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.
>> 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?
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.
The 4 classes and no other class?
> 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?
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? 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.
So, before running a poll, I'd like to understand exactly what are the
proposed options.
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.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] what else need to be done (Was: Benchmark of 0.3 vs 0.4)
Posted by Bernd Fondermann <be...@googlemail.com>.
On Tue, Aug 5, 2008 at 18:07, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann ha scritto:
>>
>> On Tue, Aug 5, 2008 at 13:41, Niklas Therning <ni...@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.
>
> 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."
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?
> Good packaging and no cycles is also very important if you plan to embrace
> library management tools ala OSGi, but they are not a blocker for me.
Well, that's a good point actually, since it highlights a disadvantage
of OSGi which in my experience requires splitting proper jars up into
artifically fragments to leverage full OSGi modularization.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] what else need to be done (Was: Benchmark of 0.3 vs
0.4)
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann ha scritto:
> On Tue, Aug 5, 2008 at 13:41, Niklas Therning <ni...@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.
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.
Good packaging and no cycles is also very important if you plan to
embrace library management tools ala OSGi, but they are not a blocker
for me.
I also think that adding documentation could take less time than all of
this discussions and would be more user-friendly, but this is utopia
existing only in my mind.
The most user friendly action we can do is releasing, so I'm happy with
any solution you will agree upon as long as it will not delay the
release (ok, we are not in hurry as we don't have a release manager,
yet, so take your time).
Stefano
PS: I repeat myself that discussion before commit and RTC does not worth
too much here and really prefer CTR and vetos, because how we do stuff
now is discuss a lot, find somehow an agreement, make a branch, have
people review, commit and only then other people care of what you
committed and complain. I'm not saying that this discussion is not
good..but I hope people will remember this thing when I'll give up
waiting weeks to form a consensus before committing code. If I committed
this stuff as the first step we would be here discussing the same way,
but at least I would have not lost time preparing a demonstrative
branch, a proposal, a JIRA issue, collecting opinions and trying to find
consensus. Is there a more agile way for us?
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] what else need to be done (Was: Benchmark of 0.3 vs 0.4)
Posted by Bernd Fondermann <be...@googlemail.com>.
On Tue, Aug 5, 2008 at 13:41, Niklas Therning <ni...@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
Re: [mime4j] what else need to be done (Was: Benchmark of 0.3 vs
0.4)
Posted by Niklas Therning <ni...@trillian.se>.
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.
/Niklas
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] what else need to be done (Was: Benchmark of 0.3 vs 0.4)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Aug 10, 2008 at 3:36 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Thu, 2008-08-07 at 12:16 +0200, Stefano Bagnara wrote:
>> Robert Burrell Donkin ha scritto:
>> > On Tue, Aug 5, 2008 at 10:53 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> >> Niklas Therning ha scritto:
>> >>> Oleg Kalnichevski wrote:
>> >>>> Stefano Bagnara wrote:
>> >>>>> Robert Burrell Donkin ha scritto:
>
> ...
>
>>
>> I moved 3 issues to 0.5. Left MIME4J-51 in 0.4 because I think we may
>> have consensus really soon on this, but I'd like to repeat that if a
>> release manager is found and he wants to release today (unlikely) I can
>> take care of reverting MIME4J-51 and move it to 0.5 so he will be ready
>> to go.
>>
>
> Since I appear to be the one who needs the 0.4 most, and no one else
> seems willing to step in I guess I could act as a release manager for
> mime4j.
> I would need SVN commit permissions
as far as i'm concerned the offer is still open
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] what else need to be done (Was: Benchmark of 0.3 vs
0.4)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2008-08-07 at 12:16 +0200, Stefano Bagnara wrote:
> Robert Burrell Donkin ha scritto:
> > On Tue, Aug 5, 2008 at 10:53 AM, Stefano Bagnara <ap...@bago.org> wrote:
> >> Niklas Therning ha scritto:
> >>> Oleg Kalnichevski wrote:
> >>>> Stefano Bagnara wrote:
> >>>>> Robert Burrell Donkin ha scritto:
...
>
> I moved 3 issues to 0.5. Left MIME4J-51 in 0.4 because I think we may
> have consensus really soon on this, but I'd like to repeat that if a
> release manager is found and he wants to release today (unlikely) I can
> take care of reverting MIME4J-51 and move it to 0.5 so he will be ready
> to go.
>
Since I appear to be the one who needs the 0.4 most, and no one else
seems willing to step in I guess I could act as a release manager for
mime4j.
I would need SVN commit permissions, though, at least temporarily.
Oleg
> We all hope that Robert after a first warm-up jSieve release will flood
> us with release votes for mime4j and mailet* :-)
>
> Stefano
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] what else need to be done (Was: Benchmark of 0.3 vs
0.4)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Tue, Aug 5, 2008 at 10:53 AM, Stefano Bagnara <ap...@bago.org> 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.
>
> +1
I moved 3 issues to 0.5. Left MIME4J-51 in 0.4 because I think we may
have consensus really soon on this, but I'd like to repeat that if a
release manager is found and he wants to release today (unlikely) I can
take care of reverting MIME4J-51 and move it to 0.5 so he will be ready
to go.
We all hope that Robert after a first warm-up jSieve release will flood
us with release votes for mime4j and mailet* :-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] what else need to be done (Was: Benchmark of 0.3 vs 0.4)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, Aug 5, 2008 at 10:53 AM, Stefano Bagnara <ap...@bago.org> 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.
+1
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] what else need to be done (Was: Benchmark of 0.3 vs
0.4)
Posted by Stefano Bagnara <ap...@bago.org>.
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.
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.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] what else need to be done (Was: Benchmark of 0.3 vs
0.4)
Posted by Niklas Therning <ni...@trillian.se>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] what else need to be done (Was: Benchmark of 0.3 vs
0.4)
Posted by Oleg Kalnichevski <ol...@apache.org>.
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
> Stefano
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org