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 "Stefano Bagnara (JIRA)" <se...@james.apache.org> on 2008/07/22 18:21:31 UTC
[jira] Created: (MIME4J-65) Message.writeTo for an rfc822 part
ignoring a "base64" encoding
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
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-65) Message.writeTo for an rfc822 part
ignoring a "base64" encoding
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616160#action_12616160 ]
Robert Burrell Donkin commented on MIME4J-65:
---------------------------------------------
Using streams and copying introduces multiple buffering but I don't want to argue. You prefer another design approach which is fine. Just go ahead and commit your proposal. As you have probably worked out, I don't really care about the DOM API. I definitely don't care enough to waste so much time arguing about it. The performance is probably not critical.
Please don't get so upset. You've done some good work over the last week or so but you need to learn to bring the community with you when you push. I thought that we'd all started to work together towards fixing things earlier this week. Unfortunately that seems not to be the case.
Robert
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-65) Message.writeTo for an rfc822 part
ignoring a "base64" encoding
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615807#action_12615807 ]
Robert Burrell Donkin commented on MIME4J-65:
---------------------------------------------
For performance reasons, it makes sense for TempFileTextBody and TempFileBinaryBody to execute the encoding. However, I agree that it's more natural for Message to manage this encoding in a more abstract way.
> 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.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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-65) Message.writeTo for an rfc822 part
ignoring a "base64" encoding
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616166#action_12616166 ]
Stefano Bagnara commented on MIME4J-65:
---------------------------------------
There are no more copies than before: I moved copies from the TempBody implementations to the Entity/Message class. There are no more copies (excluding the one specific to the bug fixed, that previously was not handled at all).
I don't think there is more buffering than before for the cases that was handled before too.
Base64Encoder has a 1024 buffer. Base64OutputStream has a 4 bytes buffer.
I tested the performance too:
I'm creating 10000 random byte sequences from 1 to 1000 bytes long (cannot test longer messages as the current implementation fails to correctly encode them).
Here are the results:
Encoder: 2538ms
Stream: 2819ms
So the stream solution is 10% slower, but we should consider that the specific test give the encoder solution
a big advantage in the fact that they always use its own 1024 buffer once and do not require iterations. There is no way to have a better comparison unless we fix the Encoder first. I don't care to fix it to prove the performance is not an issue.
mime4j is far from being usable from me, so I don't care of specific issues or specific apis too. I just wanted to exercise on this issues. At least I can use mime4j for testing purposes.
I never pushed. The community simply is upset anytime I make a move. E.g: it seems that you are getting so upset simply because I'm opening JIRAs with bugs and attacching proposals to fix them.
I thought that I would have seen a lot of bug fixing now that the test suite issue or the branch issue is not more blocking you all, too.
I've done my homework and attached stuff to JIRA (it seems it was the only place I could use without hurting people) as I don't really like the current place and the current feelings.
If anyone wants an usable DOM api they will take care of this issue and to push it. Not me. I hope they will appreciate my attempt and that this JIRA does not hurt anyone.
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-65) Message.writeTo for an rfc822 part
ignoring a "base64" encoding
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616147#action_12616147 ]
Robert Burrell Donkin commented on MIME4J-65:
---------------------------------------------
Note;
1. That the implementation you propose is not as efficient as the current solution
2. Just because you copy code from another project does not mean that the code is better tested
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-65) Message.writeTo for an rfc822 part
ignoring a "base64" encoding
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616168#action_12616168 ]
Stefano Bagnara commented on MIME4J-65:
---------------------------------------
Forgot to say that there is space for optimization in the patch I submitted: the
new Base64OutputStream(new OutputStreamWriter(new LineBreakingOutputStream(out, 76)) {
public void close() throws IOException {
// do not close wrapped stream but flush them
flush();
}
});
could be easily wrapped in a single stream filter to decrease calls and streams buffers creation. I'll leave this to him, who decide to take the code from here.
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-65) Message.writeTo for an rfc822 part
ignoring a "base64" encoding
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616353#action_12616353 ]
Robert Burrell Donkin commented on MIME4J-65:
---------------------------------------------
A single stage encoder should always be more performant than streams+copying. The downside is that the code is less readable. If performance isn't critical then it's probably worth trading some performance for maintainability.
So please go ahead and commit.
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-65) Message.writeTo for an rfc822 part
ignoring a "base64" encoding
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617134#action_12617134 ]
Robert Burrell Donkin commented on MIME4J-65:
---------------------------------------------
Re: Commit Cycle
I've become a little frustrated by this too.
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-65) Message.writeTo for an rfc822 part
ignoring a "base64" encoding
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617132#action_12617132 ]
Robert Burrell Donkin commented on MIME4J-65:
---------------------------------------------
Re: Encoding
Sorry for being unclear
In theory, a single stage that copies and encodes should be more performant that a two separate stages (copy then encode). The tradeoff is that single stage implementations are more difficult to write and maintain.
Personally speaking, I would find the single stage easier. But if you can't easily understand the algorithm then there's not much hope for anyone else. So I don't think it unreasonable to go for a more mature but less performant solution in this case. The current implementation is not mature but could be fixed. If you prefer the single stage approach, I'll find some time to fix it. If not, then that's fine.
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-65) Message.writeTo for an rfc822 part
ignoring a "base64" encoding
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615743#action_12615743 ]
Stefano Bagnara commented on MIME4J-65:
---------------------------------------
I believe there is a design issue in the current encoding/decoding behaviour.
I found a solution that fixes this issue, but it is not good because I use a temporary ByteArrayOutputStream to encode/decode output streams. The correct solution would be to encapsulate the outputstream in a Base64EncoderOutputStream, QuotedPrintableEncoderOutputStream, QuotedPrintableTextEncoderOutputStream and keep using the body.writeTo method.
Unfortunately the encoder utils are now utility and works on buffer instead of streams (I had no time to check how feasible is to convert them to stream).
Encoding/Decoding from/to Base64/QuotedPrintable is a concept that should be considered at the Message level because an Header define how to deal with a body. It does not make sense to have the body implementations (TempFileTextBody, TempFileBinaryBody to handle encoding/decoding, IMHO).
If otherwise we want to keep the encoding/decoding behaviour in the body implementations (BAD for me) then we have to correctly deal with rfc822 Message body encoding somehow.
> 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
>
>
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Resolved: (MIME4J-65) Message.writeTo for an rfc822 part
ignoring a "base64" encoding
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefano Bagnara resolved MIME4J-65.
-----------------------------------
Resolution: Fixed
Fix Version/s: (was: 0.5)
Marking as resolved.
As Robert pointed out this could be solved in a more performant way if/once MIME4J-66 and MIME4J-67 will be fixed by using the same pattern used for QuotedPrintableOutputStream.
> 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
> Assignee: Stefano Bagnara
> Fix For: 0.4
>
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (MIME4J-65) Message.writeTo for an rfc822 part
ignoring a "base64" encoding
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefano Bagnara updated MIME4J-65:
----------------------------------
Attachment: testmsgs-message-rfc822-encoding.zip
MIME4J-65.patch
Added a patch (please note the patch produce correct results / fix the bug) but introduce memory/performance issues.
The full fix will require using outputstreams for the encoding, a input-output-pipe/worker pattern, or more custom code in Message.writeTo.
> 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.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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (MIME4J-65) Message.writeTo for an rfc822 part
ignoring a "base64" encoding
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefano Bagnara updated MIME4J-65:
----------------------------------
Attachment: MIME4J-65-complete.patch
This is a full patch for this issue.
The patch remove the usage of the Base64Encoder in favor of a Base64OutputStream cloned by MyFaces Trinidad 1.2.8 (So it also solve MIME4J-66 and MIME4J-67).
It also adds a LineBreakerOutputStream to make sure the output from Base64OutputStream is also splitted in 76 chars lines.
This also introduce a QuotedPrintableOutputStream based on the existing encoder.
The encoder has been refactored to expose the utility methods used by the outputstream. The outputstream is not complete and only implements the used method (bytes per bytes write is not supported).
This patch solve correctly and perfomantly this issue.
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-65) Message.writeTo for an rfc822 part
ignoring a "base64" encoding
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616148#action_12616148 ]
Robert Burrell Donkin commented on MIME4J-65:
---------------------------------------------
Note also that you need to indicate the provinence in the commit message when you commit code from elsewhere
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-65) Message.writeTo for an rfc822 part
ignoring a "base64" encoding
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616170#action_12616170 ]
Robert Burrell Donkin commented on MIME4J-65:
---------------------------------------------
Stefano: please just commit your solution
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-65) Message.writeTo for an rfc822 part
ignoring a "base64" encoding
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Assigned: (MIME4J-65) Message.writeTo for an rfc822 part
ignoring a "base64" encoding
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefano Bagnara reassigned MIME4J-65:
-------------------------------------
Assignee: Stefano Bagnara
> 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
> Assignee: 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-65) Message.writeTo for an rfc822 part
ignoring a "base64" encoding
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616150#action_12616150 ]
Stefano Bagnara commented on MIME4J-65:
---------------------------------------
1. Can you prove this?
1b. THe current solution has bugs. We have to first fix them if we want to compare performance, anyway.
2. I agree. Simply this one is working. THe current one not.
I've nothing against your code. I simply take care of the result: I wanted a working solution and I wanted to propose something instead of writing useless complaints.
Either you decide to use this or not I don't care at all.
I'm not committing code anywhere, anymore. If anyone will decide they want to use the code I've explained that the Base64OutputStream class has been copied from MyFace Trinidad.
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-65) Message.writeTo for an rfc822 part
ignoring a "base64" encoding
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617165#action_12617165 ]
Stefano Bagnara commented on MIME4J-65:
---------------------------------------
Re: Encoding
I agree on your single stage vs two stage concern. Just I'd like to repeat (because I have doubts you missed this) that in the case of my refactoring for the Quoted-Printable we are talking about single stage vs single stage, the only thing changing is the way we expose the service. There is no performance changes because there is no change in what the CPU will end up doing: it is simply a different OOP paradigm. It is a read-encode-write-out vs read-and-write-on-encoding-out. In both cases we have a buffer read from the input stream a method that given the buffer writes the encoded version in output. There is no single write operation introduced by the QuotedPrintableOutputStream.
About the Base64 I would be happy to reuse your code if you find the time to fix the 2 issues I reported.
My approach to similar stuff is that we now should apply the mature stuff but we don't close the 2 Base64Encoder issues (just let's change their priority to minor). If anyone will decide to fix them we can easily move back to use the Base64Encoder.
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-65) Message.writeTo for an rfc822 part
ignoring a "base64" encoding
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616355#action_12616355 ]
Robert Burrell Donkin commented on MIME4J-65:
---------------------------------------------
Stefano - please reconsider waking away from committing. I said a number of things in haste that I now regret. It was an error of judgement. I'm sorry.
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-65) Message.writeTo for an rfc822 part
ignoring a "base64" encoding
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615816#action_12615816 ]
Stefano Bagnara commented on MIME4J-65:
---------------------------------------
Are you talking about alternative implementations of the Text/Binary body that could avoid decoding/reencoding when no one ask for the decoded or for a differently encoded version?
At the moment the specific behaviour we have in the TempFile*Body classes could be replicated in the Entity.writeTo, but we would need anyway a fix for the message/rfc822 body parts.
e.g:
private void writeToFile(Body b, File mime4jFile)
throws FileNotFoundException, IOException {
if (b instanceof TextBody) {
String charset = CharsetUtil.toJavaCharset(b.getParent().getCharset());
if (charset == null) {
charset = "ISO8859-1";
}
OutputStream out = new FileOutputStream(mime4jFile);
IOUtils.copy(((TextBody) b).getReader(), out, charset);
} else {
OutputStream out = new FileOutputStream(mime4jFile);
IOUtils.copy(((BinaryBody) b).getInputStream(), out);
}
}
So for TextBody and BinaryBody we could replicate something similar to get the stream (clone the IOUtils method to deal with Reader, create a ReaderInputStream and so on) but we need a solution for the message/rfc822 (instanceof Message) case, first.
Is creating OutputStreams for QP and Base64 the only solution? Any alternative ideas?
> 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.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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org