[ 
https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529186
 ] 

Jochen Wiedmann commented on MIME4J-30:
---------------------------------------

I do not understand your last comment, Robert. Why do you not like the 
getInputStream(boolean)? IMO, supplying the boolean variable to the constructor 
is a *very* bad solution, because typically you want to decode in very few 
cases (for example when a special transfer-encoding is used). Within the 
constructor you do not know the transfer-encoding. However, when invoking 
getInputStream(boolean) you have all required informations.


> Transfer-encoding should be transparent
> ---------------------------------------
>
>                 Key: MIME4J-30
>                 URL: https://issues.apache.org/jira/browse/MIME4J-30
>             Project: Mime4j
>          Issue Type: Improvement
>    Affects Versions: 0.3
>            Reporter: Jochen Wiedmann
>            Assignee: Robert Burrell Donkin
>             Fix For: 0.4
>
>         Attachments: mime4j-transfer-encoding.patch, 
> mime4j-transfer-encoding.patch
>
>
> Currently the mime4j user must be aware of the transfer-encoding header.
> a) This is inconvenient. I can think of no reason, why a user should want the 
> encoded data stream.
> b) This blocks MIME4J-27 in the following sense: If a user configures a limit 
> on the attachments size,
>      then this should most possibly limit the decoded attachments size. But 
> Mime4j can only track
>      the decoded attachments size, if it is itself responsible for decoding.

-- 
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]

Reply via email to