On 08/09/2013 09:55 PM, Darryl L. Pierce wrote:
The fix was to default encode strings from Ruby, Python and Perl using UTF-8.
I have a couple of questions about this. While I certainly agree that sending data as vstr is nearly always the right thing, the changes you made - assuming I read them correctly - don't simply alter the 'default' encoding but prevent any other encoding. (Any attempt to do so would indeed result in decoding errors at the other side rather than simply a loss of desired encoding).
So for example it would no longer be possible to send a map message with binary data within it. It may be that is considered sufficiently unlikely a requirement that it has been explicitly discounted.
I'm not saying that is necessarily the wrong decision, but I feel it warrants a little bit more commentary/explanation.
Python has a unicode string for example, which presumably(?) could be used to explicitly choose utf8 encoding. Was that approach considered and rejected?
From your change it looks like for perl someone had previously explicitly checked whether a string was a UTF8 one when choosing the encoding and you have removed that check. Did the existing code not work or was it felt to be unintuitive to users? (Also, minor nit, you checked in commented out code rather than removing it).
Again, I am not necessarily opposed to the changes. I just want to be sure that sufficient thought has been given as to the consequences (and alternatives).
I verified it with the Perl and Ruby clients again the Java Drain tool and it works correctly.
What about python?
The JIRAs are: QPID-5067: Default string encoding for dynamic languages should be UTF-8 QPID-4835: JMS client is unable to read the application headers of messages sent by the ruby clients I asked Weston to verify it for me.
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
