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 "Jochen Wiedmann (JIRA)" <se...@james.apache.org> on 2007/09/19 02:26:43 UTC
[jira] Created: (MIME4J-30) Transfer-encoding should be transparent
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
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
[jira] Commented: (MIME4J-30) Transfer-encoding should be
transparent
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529252 ]
Robert Burrell Donkin commented on MIME4J-30:
---------------------------------------------
getInputStream(boolean) makes no sense when the state is raw, preamble or epilogue. Added a new getRawContent() method suitable only for body would be better than abusing the getInputStream method. (But no need to alter your patch.)
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (MIME4J-30) Transfer-encoding should be transparent
Posted by "Jochen Wiedmann (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jochen Wiedmann updated MIME4J-30:
----------------------------------
Attachment: mime4j-transfer-encoding.patch
Proposed patch with a slightly different solution: Introduces a new method
getInputStream(boolean pTransferDecoding)
with getInputStream() being implemented as getInputStream(true). This has the advantage, that it can be used case by case. Additionally, the interface is polluted with only one additional method, as opposed to a getter and a setter.
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-30) Transfer-encoding should be
transparent
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529171 ]
Robert Burrell Donkin commented on MIME4J-30:
---------------------------------------------
Adding getInputStream(boolean pTransferDecoding) would go against the grain of the existing API. The output of this method is already controlled (indirectly) by a state variable and the boolean would only have meaning in one state. I agree about the polluation with getters and setters: I would inject this variable upon construction only.
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-30) Transfer-encoding should be
transparent
Posted by "Jochen Wiedmann (JIRA)" <se...@james.apache.org>.
[ 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-30) Transfer-encoding should be
transparent
Posted by "Jochen Wiedmann (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528995 ]
Jochen Wiedmann commented on MIME4J-30:
---------------------------------------
Robert, as for the buffer handling: I am *debugging* (as opposed to preparing, or writing) a patch that introduces buffering into the MimeTokenStream. And, indeed, that patch will remove the Cursor interface in favour of the interface below. I have initially attempted to implement the Cursor interface, but found it to be a massive complication. In particular, it fixes the communication between Cursor and MimeTokenStream to be an InputStream, which is quite nasty in the context of buffers.
I have basically no problems with adding a switch, if we can agree that enabling access to the undecoded stream and limiting the attachments size are mutually exclusive actions.
public interface ByteArrayFetcher {
/**
* Returns the buffer, which is offered to the caller. The caller may
* use this buffer until the next call to {@link #getAvailableBytes()},
* but not longer.
*/
byte[] getBuffer();
/**
* Returns the offset in the buffer, from which the caller
* may read bytes.
*/
int getOffset();
/**
* Asks the byte array fetcher for more data. If data
* is available, returns the number of bytes, which are
* ready for consumation. If so, the caller must invoke
* {@link #getBuffer()} and {@link #getOffset()} to query
* for the data location.
* @return Number of bytes, which are ready, or -1, if
* end of stream is reached.
* @throws IOException An I/O error occurred while asking for more data.
*/
int getAvailableBytes() throws IOException;
/**
* Terminates use of the byte array fetcher. The fetcher will
* free resources. The method {@link #getAvailableBytes()} will
* throw an {@link IOException} from now on.
*/
void close() throws IOException;
}
> 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
[jira] Commented: (MIME4J-30) Transfer-encoding should be
transparent
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529243 ]
Robert Burrell Donkin commented on MIME4J-30:
---------------------------------------------
ByteArrayFetcher is a low level interface. Cursor is a high level one. A high level interface would allow more efficient support for non-streaming partially structured solutions.
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-30) Transfer-encoding should be
transparent
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529221 ]
Robert Burrell Donkin commented on MIME4J-30:
---------------------------------------------
The only use cases I know are ones where the mime body part should never be decoded (regardless of the transfer-encoding).
Adding a boolean goes against the grain of the design of the rest of the API. A similar case (raw entities) is handled by using a field rather than a parameter. The parameter would only make sense when within a body: other parts would ignore it.
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Closed: (MIME4J-30) Transfer-encoding should be transparent
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Burrell Donkin closed MIME4J-30.
---------------------------------------
Resolution: Fixed
Assignee: Robert Burrell Donkin (was: Jochen Wiedmann)
Committed Oleg's patch. Many thanks.
Hopefully this should satify everyone.
> 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, mime4j.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
[jira] Updated: (MIME4J-30) Transfer-encoding should be transparent
Posted by "Jochen Wiedmann (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jochen Wiedmann updated MIME4J-30:
----------------------------------
Attachment: mime4j-transfer-encoding.patch
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-30) Transfer-encoding should be
transparent
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (MIME4J-30) Transfer-encoding should be transparent
Posted by "Oleg Kalnichevski (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski updated MIME4J-30:
------------------------------------
Attachment: mime4j.patch
A lightly different take than Jochen's. The main difference is that I left automatic content decoding optional.
Please review.
Oleg
> 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: Jochen Wiedmann
> Fix For: 0.4
>
> Attachments: mime4j-transfer-encoding.patch, mime4j-transfer-encoding.patch, mime4j-transfer-encoding.patch, mime4j.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
[jira] Assigned: (MIME4J-30) Transfer-encoding should be
transparent
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Burrell Donkin reassigned MIME4J-30:
-------------------------------------------
Assignee: Jochen Wiedmann
Hi Jochen
AIUI you have karma now
IMHO the best approach would be to go ahead and apply your patches to bring the JAMES version close to your current design. It should be discuss changes needed for the other use cases once this has been done. I'll take up the design discussion on list.
> 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: Jochen Wiedmann
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Assigned: (MIME4J-30) Transfer-encoding should be
transparent
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Burrell Donkin reassigned MIME4J-30:
-------------------------------------------
Assignee: Robert Burrell Donkin
> 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
[jira] Commented: (MIME4J-30) Transfer-encoding should be
transparent
Posted by "Jochen Wiedmann (JIRA)" <se...@james.apache.org>.
[ 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-30) Transfer-encoding should be
transparent
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ 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
[jira] Commented: (MIME4J-30) Transfer-encoding should be
transparent
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529244 ]
Robert Burrell Donkin commented on MIME4J-30:
---------------------------------------------
Cursor allowed buffering to be managed in the io layer. Pushing buffering into MimeTokenStream means that the io layer can no longer transparently support this. ByteArrayFetcher uses a byte array. This means that nio buffered implementations are going to be forced to double buffer. ByteArrayFetcher also has a number of methods which would be unnecessary if a bytebuffer were used instead.
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-30) Transfer-encoding should be
transparent
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610823#action_12610823 ]
Robert Burrell Donkin commented on MIME4J-30:
---------------------------------------------
Hey Jochen
Are you going to be able to find time to update and apply your patch or shall we move this to 0.5...?
> 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: Jochen Wiedmann
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (MIME4J-30) Transfer-encoding should be transparent
Posted by "Jochen Wiedmann (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jochen Wiedmann updated MIME4J-30:
----------------------------------
Attachment: mime4j-transfer-encoding.patch
Proposed patch
> 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
> 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
[jira] Commented: (MIME4J-30) Transfer-encoding should be
transparent
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529253 ]
Robert Burrell Donkin commented on MIME4J-30:
---------------------------------------------
The question is not really about the Cursor interface but about whether Mime4J intends to support only streaming. That's probably one that should be asked on the list.
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-30) Transfer-encoding should be
transparent
Posted by "Oleg Kalnichevski (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606302#action_12606302 ]
Oleg Kalnichevski commented on MIME4J-30:
-----------------------------------------
Folks,
Is there anything I could do to help get this one moving forward?
Oleg
> 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: Jochen Wiedmann
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-30) Transfer-encoding should be
transparent
Posted by "Jochen Wiedmann (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529259 ]
Jochen Wiedmann commented on MIME4J-30:
---------------------------------------
Robert, I do not get how this discussion escalates. If we do support "only streaming", in combination with NIO (aka byte buffers), then we do support everything. But that's not even the issue here. Currently, we are simply discussing my proposal to make transfer encodings transparent. Nothing more, and nothing less.
> 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
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Assigned: (MIME4J-30) Transfer-encoding should be
transparent
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Burrell Donkin reassigned MIME4J-30:
-------------------------------------------
Assignee: (was: Robert Burrell Donkin)
> 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
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-30) Transfer-encoding should be
transparent
Posted by "Jochen Wiedmann (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529249 ]
Jochen Wiedmann commented on MIME4J-30:
---------------------------------------
Please, let's have the discussion on the Cursor interface in another issue. I intriduced it here only to demonstrate to you, that the Cursor interface is (at least IMO) questionable anyways.
For now, let's stick to the admission that StreamCursor is hard coded anyways and that it's hard to refuse a patch just because it casts the cursor to StreamCursor.
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org