Gordon,
any plans to address this metadata string encoding issue in the clients?
I guess there is some consensus now as to how this could be done...
Cheers
Jiri
On Sep 22, 2011 2:34 PM, "Gordon Sim" <g...@redhat.com> wrote:
> 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
>
