[
https://issues.apache.org/jira/browse/MIME4J-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616371#action_12616371
]
Stefano Bagnara commented on MIME4J-65:
---------------------------------------
"A single stage encoder should always be more performant than
streams+copying.": is this specific to this patch or a generic statement?
There's technical merit in this, and it's interesting sometimes to discuss
technical solutions.
Previously we had:
Body.writeTo to call this:
- CodecUtil.encodeQuotedPrintable(inputStream, out);
Now we have Body.writeTo to call this:
- out = wrapOutputInQuotedPrintableOutputStream(out);
- CodecUtil.copy(inputStream, out);
Looking at their code we have the first encoding doing this:
- create a new QuotedPrintableEncoder and calls its encode(in, out).
- loop:
- read a 1024 buffer
- encode it (encoder.encodeChunk)
- encoder write it to output
The new code instead does this:
- Calls CodecUtil.copy(in, out) that
- loop:
- read a 1024 buffer and pass (DOESN'T MAKE COPY) it to
QuotedPrintableOutputStream.write
- QuotedPrintableOutputStream.write calls (encoder.encodeChunk) using the
same identical buffer of the previous solution.
- encoder write it to output
Really, I'm not seeing the copy and the performance issue you keep talking
about and I'm not going to commit while I can think I've knowledge issues wrt
streams and buffer management.
The only difference I can see between the 2 methods is that the outputstream
introduce 1 more method call: let's make it final if this concern you and I bet
the JVM will optimize it.
Generic comment about committing stuff myself: I'm currently working on
something else in mime4j now and I don't have a clean checkout to reapply the
patches and commit. If you are in hurry please go ahead and commit them
yourself, otherwise I'll do this in future once it will be more clear a
solution for each of the bugs I'm tracking and every patch will have been
vetted. I don't want to waste time by creating patches, discussing each line of
them and the having also to reapply the patches locally to commit (at least I
have to batch this in order to optimize my time). I thought we was in CTR, but
this is CTLTF Commit-then-Look-The-Flames, so RTDALASFAWAC
Review-then-Discuss-a-Lot-and-Sleep-for-a-While-and-Commit seems the most agile
approach we can have now ;-)
> Message.writeTo for an rfc822 part ignoring a "base64" encoding
> ---------------------------------------------------------------
>
> Key: MIME4J-65
> URL: https://issues.apache.org/jira/browse/MIME4J-65
> Project: Mime4j
> Issue Type: Bug
> Affects Versions: 0.4
> Reporter: Stefano Bagnara
> Fix For: 0.4, 0.5
>
> Attachments: MIME4J-65-complete.patch, MIME4J-65.patch,
> testmsgs-message-rfc822-encoding.zip
>
>
> the writeTo method for a Content-Transfer-Encoding: base64 and Content-Type:
> message/rfc822 part writes the message unencoded.
> I would expect it to be encoded in a base64 stream. See MIME4J-64 for an
> useful test.
--
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]
