[
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 [EMAIL PROTECTED]
#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
* [EMAIL PROTECTED] #getBuffer()} and [EMAIL PROTECTED] #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 [EMAIL PROTECTED] #getAvailableBytes()} will
* throw an [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
