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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
