james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefano Bagnara (JIRA)" <mime4j-...@james.apache.org>
Subject [jira] Created: (MIME4J-154) ContentHandler should rely on MimeStreamParser.setContentDecoding instead of dealing with their own transfer decoding code.
Date Wed, 30 Dec 2009 14:06:29 GMT
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.


Mime
View raw message