Bernd Fondermann ha scritto:
On Tue, Aug 5, 2008 at 13:41, Niklas Therning <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
