On 09/21/2011 04:20 PM, Fraser Adams wrote:
I checked up on the producer client code and it's doing:
message.getHeaders().setString("key", "value");
where key and value are sensible things :-)
That essentially is the first of the two options listed. There is no
checking or conversion. If the value was not valid utf8 then the message
would be incorrectly encoded (and e,g the python and java client would
be unable to decode it).
With qpid::messaging my tests have done:
message.setProperty("key", "value");
The "setString" in qpid::client thus appears to populate UTF8 Strings
(we're definitely having those interoperate with JMS consumers using
UTF-8 Address Strings).
Perhaps the simple option then is to modify the qpid::messaging API to
be even more JMS like and be a bit more explicit in the method names
with respect to the property types (perhaps it already supports this and
I simply haven't noticed??
That is one option; we could add a method(s) that is more explicit as to
the encoding of the value (I wouldn't want to remove the existing method
and break the API). E.g.
message.setUtf8Property("key", "value");
It would be clear that it is the applications responsibility to ensure
that the data is indeed utf8.
A similar (and I think nicer) solution would be e.g
message.setProperty("key", utf8("value"));
This is perhaps slightly less obvious than an explicitly named method
but that could be addressed with some clear reference documentation for
the method (needed anyway of the generic setProperty() remains unchanged).
Or as you suggested originally we could simply assume utf8 by default if
no other encoding is specified in this context. I would lean to doing
this without checking for the reasons mentioned in an earlier mail. The
fact that this matches what the old API does is a fair sign that it will
not cause great confusion!
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
