[
https://issues.apache.org/jira/browse/MIME4J-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefano Bagnara resolved MIME4J-154.
------------------------------------
Resolution: Fixed
Merged from cycleclean branch.
> ContentHandler should rely on MimeStreamParser.setContentDecoding instead of
> dealing with their own transfer decoding code.
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: MIME4J-154
> URL: https://issues.apache.org/jira/browse/MIME4J-154
> Project: JAMES Mime4j
> Issue Type: Improvement
> Affects Versions: 0.6
> Reporter: Stefano Bagnara
> Assignee: Stefano Bagnara
> Priority: Minor
> Fix For: 0.7
>
>
> Both MessageBuilder and SimpleContentHandler have special code to recognize
> the transfer-encoding and decode the inputstream using the Base64InputStream
> or the QuotedPrintableInputStream. This is a worse practice as
> MimeStreamParser now have the setContentDecoding, so the caller should simply
> set that property to true and the content handler will receive decoded
> streams.
> We should "hide" the common task behind a single entry point. The fewer
> classes we ask to use to our downstream users, the easier will be to track
> compatibility, upgrading, and so on. If to use mime4j in basic ways people
> have to create classes from all of our packages then it will be a PITA.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
