Oleg Kalnichevski ha scritto:
Stefano Bagnara wrote:
Oleg Kalnichevski ha scritto:
On Sat, 2008-07-19 at 18:29 +0200, Stefano Bagnara wrote:
Oleg Kalnichevski ha scritto:
...
...
<rant disclaimer="please ignore">
HttpComponents project chose to depend on mime4j instead of developing a
similar solution because we thought it was the right thing to do. We
thought we should rather contribute to an existing project instead of
pursuing competing efforts for which we have neither resources nor the
right expertise.
As a result we had to delay the next release of HttpClient by almost two
months waiting for a mime4j release. I do not see a point in waiting any
longer. I see no other way but dropping dependency on mime4j, at least
temporarily.
I did my very best to resolve an old problem no one seemed eager to work
on for a year and a half. I will happily continue to contribute to this
project to my best abilities, but in this particular case I see no
justification to investing any more time in trying to satisfy someone
else's wish list.
</rant>
Please note that I never expected you to satisfy any wishlist. I
simply opened the project and tested some code and I found issues. I
simply reported issues. I also tried to help with the repackaging
because it is something that I always found interesting (I also wrote
a tool that automatically try to make automatic package classification
based on dependencies and some metric).
I'm not (I never did) asking you to solve any of mime4j issues (my
last sentence you quoted is "I'm not saying that I want mime4j to
support all of this before a release, I just want to understand if
this is what you also expect and if this can be considered a common
goal..": I'm not sure I understand your rant and why you think I'm (or
someone else) asking you to do something. In fact we even voted to
make you committer to this project so you could have worked on the
code without waiting for our limited time to review/apply patches.
Most of the issues I opened against Mime4j are simply there because
they need attention: there is no need to solve them in order to make a
release.
Some other issue instead require attention (e.g: the quoted printable
stuff no more being decoded), but this is not something we are asking
you to solve. I'm not sure when I'll find the time but I plan to try
to understand when this has been broken and how to fix it.
Infinite loops and other OOM issues are there: I think I'm not the
cause of them, and I understand that is frustrating for you to find
critical issues in a library you introduced in your component but
please think twice to this.
Most of this issues are regression against old mime4j versions and
Niklas did a good job in givin trunk a go and testing it in his
environment.
I hope you understand I'm propositive in this discussion and I'm
simply trying to understand the common goal so that we don't break
each other work.
(1) Replacing a simple algorithm with a much more complex one is usually
bound to produce regressions.
Sure.
(2) when the refactoring was completed _all_ existing tests passed. If
there had been more tests I would have ensured they all passed as well.
OOM issues were present in the old implementation. Handling of binary
content was broken before me. It is somewhat unfair to blame me for
breaking functionality that was not covered by test cases.
No one blamed you because of this regressions or because of missing
tests. We are here to collaborate and make things better. No one blamed
you of the OOM or the infinite loops.
I simply reported them to JIRA as I found them. I think it is better to
have opened JIRAs than ignoring issues.
Are you blaming me because I opened JIRA issues??
(3) I was quietly working on fixing reported issues and regressions
until we got stuck in this 'discussion' about line delimiters. It
dragged on for days without producing any practical outcome and was
mostly about pointless stuff.
No one ever asked you to implement any specific line delimiter handling.
In fact I'm willing to code the solution myself once it is clear what is
the correct approach for a similar library and what kind of options we
need to make it simple but flexible as needed.
If you are willing to partecipate to this discussion you are very
welcome, but if this discussion scare you simply ignore it and limit
yourself describing the behaviour you need in httpcomponent. I don't
really expect you accomodate any request from me (or us) or to satisfy
our wishlist. Never did that.
I will happily continue fixing known regressions, but I feel there is
nothing else I could contribute to this issue. The best thing to do now
is for me to step aside and let you implement whatever solution you feel
appropriate.
This sounds acceptable. You described HTTP needs now (but to correctly
understand your needs we had to have this discussion, otherwise it was
not clear to me, and probably others, that you need LF parsed as newline
and CR ignored and no other option is valid) so we can continue this
discussion (with or without you) and keep your requirement in consideration.
Please just tell me if you are working on any opened JIRA so that we
don't work on the same issue.
That's fine. Just let me understand: you wouldn't like to have mime4j
parsing also CR as newline, right?
I personally would prefer to be able to configure mime4j to do that,
because this would be consistent with the behavior of HTTP components,
but can live with CR treated as newlines.
What do you expect from mime4j when a
CR is found around the mime stream?
Ignore it
Thank you,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
