[
https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529245
]
Jochen Wiedmann commented on MIME4J-30:
---------------------------------------
The difference between the access to the raw entity and the access to the body
is, that the parser must know in advance, whether it should produce a raw
entity: If so, it creates a different event. Please, keep in mind, that the raw
entity stuff was created when the pull parser API wasn't available. I see no
reason to stick to design decisions, which have been dictated by the event API.
Access to the body has no influence on the state model. The method
getInputStream() provides access to the atomic body. There is no need for the
user to cut a decision early. He or she can do so at any time. Note, that we
could support the getInputStream(boolean) method even with the event API.
I am sure, that your proposal creates a larger patch, provides less
flexibility, is less clean (at least I consider multiple constructors to be
more ugly than method parameters)
However, If you insist, I'd rather see the flag than the constructor parameter,
because it is clearly more flexible. In order to move this forward, I'll apply
a third patch with methods set/isRawBody.
> 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]
