You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mime4j-dev@james.apache.org by "Stefano Bagnara (JIRA)" <mi...@james.apache.org> on 2009/12/30 15:06:29 UTC
[jira] Created: (MIME4J-154) ContentHandler should rely on
MimeStreamParser.setContentDecoding instead of dealing with their own
transfer decoding code.
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.8
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.
[jira] Resolved: (MIME4J-154) ContentHandler should rely on
MimeStreamParser.setContentDecoding instead of dealing with their own
transfer decoding code.
Posted by "Stefano Bagnara (JIRA)" <mi...@james.apache.org>.
[ 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.