Oleg Kalnichevski ha scritto:
On Thu, 2008-07-17 at 20:21 +0200, Stefano Bagnara wrote:
Oleg Kalnichevski ha scritto:
Stefano Bagnara wrote:
...
Not only does this change completely reverts the performance gains and
makes the whole refactroring exercise completely pointless due to an
utterly inefficient implementation of EOLConvertingInputStream, it is
also conceptually wrong (in my humble opinion), as it causes mime4j to
corrupt 8bit encoded 'application/octet-stream' content. This basically
renders mime4j incompatible with commons browsers and HttpClient
The performance of the EOLConvertingInputStream is not important at all
if removing it we have an unusable library.
And the last thing. This kind of argument works both ways. The strict
RFC compliance is not important if we have an unusable library as a
result.
Oleg, I agree with you! I'm well aware of this.
I think that slowly this discussion is givin a bit more knowledge to
judge what is the right compromise between strict behaviour, permissive
interoperabily and compliance.
Most time there is no need to be non-compliant to support permissive
interoperability but we just need to be less strict.
I hope you understand I'm not fighting your patch/changes and I'm even
much more far from fighting you (in fact I like you because you provide
code and not complaints!). I want to make sure we do the right thing
because we understand it or if we do the wrong thing I want to be sure
we understand what we are doing and agree that even if it is wrong is
acceptable to us.
E.g: I'm slowly coming to a possible proposal about parsing.
- strict mode: no conversion is done, a CR or LF in headers (or other
non 7bit content) make mime4j fail parsing.
- permissive modes:
- default binary: no conversion happen, isolated CR and LF are
accepted everywhere but not considered newlines (as like as other 8bit
bytes), the default content-transfer-encoding is "binary" when not
specified (7bit, 8bit and binary are read as binary).
- default text: we convert isolated CR and LF to CRLF almost
everywhere but in "binary" content-transfer-encoding parts.
I'm not proposing this yet (not sure this is enough and we don't need
more granular tweakings), but this is something I'm evaluating right
now... The strict mode is desiderable to have, but less important than
the permissive parsing (we want to be strict in output, not in input).
OTOH someone may want to use mime4j for validating if a content is
wellformed or not (wrt RFC) and in this case a strict mode would be
necessary.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
