[
https://issues.apache.org/jira/browse/MIME4J-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995833#comment-12995833
]
Oleg Kalnichevski commented on MIME4J-164:
------------------------------------------
Rohan
Presently mime4j I/O classes are designed around the concept of spitting the
input stream into relatively short (<100KB) lines of text. In my opinion this
is a fairly reasonable assumption given that the MIME standard requires long
lines to be folded.
I looked into the possibility of redesigning the low level I/O classes and
changing the underlying representation of a MIME field from an expandable
in-memory buffer to an InputStream and had to conclude this would likely
require pretty much a complete rewrite of larger parts of the core module.
Frankly, given we are dealing with a fairly extreme case here, I am very
reluctant to have a yet another rewrite of the core classes. I am not convinced
the potential benefits actually outweigh extra complexity that this change may
entail.
What we could do, though, without throwing a half of the core module away is to
provide an option to have very long _folded_ line truncated once the max line
limit has been reached.
I am going to close this issue as WONTFIX and concentrate on fixing MIME4J-165.
If anyone feels like picking this issue up, please re-open it and reassign it
to a later release (0.8).
Oleg
> Incremental address list field parsing
> --------------------------------------
>
> Key: MIME4J-164
> URL: https://issues.apache.org/jira/browse/MIME4J-164
> Project: JAMES Mime4j
> Issue Type: Improvement
> Affects Versions: 0.6
> Environment: Java 6
> Reporter: Rohan Hart
> Priority: Minor
> Fix For: 0.7
>
>
> To avoid buffer limits it would be good for address list field parsing to
> interleave reading the stream with parsing individual addresses.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
