On 08/19/2013 05:00 PM, Gordon Sim wrote:
On 08/19/2013 04:39 PM, Darryl L. Pierce wrote:
On Mon, Aug 19, 2013 at 04:20:01PM +0100, Gordon Sim wrote:
On 08/19/2013 03:21 PM, Darryl L. Pierce wrote:
The fundamental issue is that, regardless of the dynamic language,
properties aren't being encoded as UTF-8 at all.
Even if, in Perl, they are being set as UTF8? Are you saying that
the existing test in the Perl bindings doesn't work (i.e. doesn't
actually allow you to chose between utf8 or binary)?
What I'm saying is that, when the properties for Perl, Python and Ruby
are sent to a Java receiver, the Java receiver doesn't see the
properties (per the original JIRA).
The code for the perl binding has the following test:
STRLEN len;
char *ptr = SvPV(value, len);
qpid::types::Variant v = qpid::types::Variant(std::string(ptr,len));
if (SvUTF8(value)) {
v.setEncoding("utf8");
}
I presume this is supposed to test whether the value passed in is UTF8
(this is before we have encoded it into the AMQP wire format).
So, my question is whether you are saying that the test above (i.e. the
if statement) does not in fact work for some reason as a way to
determine whether to encode as str or bin?
Answering my own question through some experimentation, it appears it
does work. I.e. I can utf8::upgrade() a property value before setting it
and it is then encoded as str16.
So for perl at least, you can at present send properties (and values in
maps and lists) as either utf8 strings or binary strings. The question
would then seem to be simply whether that choice can be made simpler,
nicer, more intuitive etc to users(?).
A similar approach could be taken in python, by encoding unicode strings
as strs and 'normal' strings.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
