You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org> on 2007/09/19 21:57:12 UTC
[jira] Commented: (MIME4J-30) Transfer-encoding should be
transparent
[ https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528877 ]
Robert Burrell Donkin commented on MIME4J-30:
---------------------------------------------
This patch reintroduces back into MimeTokenStream the dependency on streaming that I eliminated in order to allow buffers to be parsed efficiently. If this is really necessary then we should remove the Cursor interface completely and accept that Mime4J will only ever support streaming solutions.
I suspect that the encoded data stream would be required for some use cases including Cypto and IMAP but I agree that it would be more intuitive for a decoded stream to be returned at least as the default.
If the goal is simple to ensure that getInputStream() returns transfer-decoded for body then I should be able to apply an alternative patch which introduces a variable to control this behaviour without reintroducing the streaming. Would this be good enough?
> 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
>
>
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org