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