[
https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529246
]
Robert Burrell Donkin commented on MIME4J-30:
---------------------------------------------
I don't really understand your point about getInputStream. In the end, the API
chooses to expose data as InputStreams so there's no getting away from it. I
found that the basic design of the parser meant that it was difficult to
buffer. It's possible that this (and not cursor) is the source of your problems.
Using ByteBuffers would allow MimeTokenStream to use the limited read ahead it
needs and communicate the correct start position by setting the position
correctly on the buffer.
> 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, 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]
