On 09/21/2011 06:10 PM, Fraser Adams wrote:
If the encoding fails an exception can be thrown - and as it really
ought to be a UTF8 string quite rightly IMHO. Question though does it
actually fail during the encoding process or is the encoding just wrong
and thus risks confusing JMS etc. clients?
Actually it won't fail on encode, but the encoded data will be
incorrectly labelled and e.g. the JMS client would likely fail on decode.
<snip>
I wonder if a better direction would be the opposite:
message.setProperty("key", binary("value"));
In other words having an assumption of UTF8 as the default, but giving
an option to explicitly break things - oops I mean use a binary value
:-D (you can see where I stand on this can't you!!).
I think you would have utility functions to set various encodings
explicitly (which are just shorthands for the existing mechanism) and
the default would be orthogonal to that.
I do actually
quite like the idea of extending it with the "JMS like" approach of
having a "generic" accessor/mutator plus additional accessor/mutators
that are more type specific I personally think that it makes the
"intent" a lot clearer. If I saw setString() I'd expect a string and if
someone put something else in it then they're an idiot and deserve what
they get :-D
I think if we go that route then setUtf8Property() would be even clearer
(that would just be an alternative to setProperty(key, utf8(value)).
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscr...@qpid.apache.org
