[
https://issues.apache.org/jira/browse/MIME4J-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653281#action_12653281
]
Oleg Kalnichevski commented on MIME4J-60:
-----------------------------------------
@Stefano
> (having 6 places dealing with newlines seems conceptually wrong to me, but
> I'm not developing mime4j so I won't object coding styles)
This has been discussed on more than one occasion. The input stream filter
solution you suggested would render mime4j completely useless for mime streams
with binary coded parts. As much as I would prefer this problem solved at the
filter level, it just does not seem possible. Presently I see no alternative to
dealing with line delimiters selectively at several places.
I will take another stab at the problem in the coming days / weeks. My plan is
to use pretty much the same simple strategy pattern approach I proposed earlier
but support only two possible modes (strict / lenient). This should ensure
consistency of the line delimiter handling code across the codebase.
Please let me know if you have any objections
Oleg
> Configurable strategy for line delimiters
> -----------------------------------------
>
> Key: MIME4J-60
> URL: https://issues.apache.org/jira/browse/MIME4J-60
> Project: JAMES Mime4j
> Issue Type: Wish
> Affects Versions: 0.4
> Reporter: Stefano Bagnara
> Fix For: 0.6
>
> Attachments: MIME4J-60-readLine-returns-no-newline.patch,
> newlines-tests.zip, newlinestrat.patch
>
>
> There is an ongoing discussion about how we should deal with non canonical
> line endings (isolated LF and/or isolated CR).
> This issue is to track discussion results and proposed patches.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
