P

[Alan Conway <ac...@redhat.com>]

On Tue, 2014-09-09 at 20:53 +0200, Rob Godfrey wrote:
> On 9 September 2014 20:39, Fraser Adams <fr...@blueyonder.co.uk>
> wrote:
> 
> > I'm afraid that your response was as clear as mud to me Rob, I'm having a
> > "thick" day today :-(
> >
> > I did read the spec. and the RFCs, but frankly I work best with concrete
> > examples.
> >
> > You say "
> >
> > the content type is (only) to be used when the data is being
> > sent as an opaque "data" section and in that case it enables the recipient
> > to interpret the opaque data correctly
> >
> > "
> >
> > That's interesting, and seems a bit overrestrictive.
> >
> >
> So the rationale here is that if you put in "text/plain; charset="utf-16"'.
> or something, then what does that mean?  The AMQP spec says that a string
> is encoded in utf8...  As you said in you original mail, the AMQP type
> system is supposed to be rich enough that it can be used to describe any
> type.  The content type is designed for the case where the data being
> transferred is not encoded in the AMQP type system, but instead presented
> as opaque binary data in AMQP terms.
> 
> 
> > As I say I'd quite like to use "application/json" so that I can use AMQP
> > String but have the application interpret that as JSON, which seems like a
> > perfectly reasonable use of the general concept of content-type and
> > certainly how one would use content-type in something like HTTP (which I
> > would have assumed that the AMQP 1.0 behaviour would most reasonably have
> > been modelled after).
> >
> >
> So - following the logic of the AMQP type system once could suppose that
> the intended patern here would be to create a new described type (let's say
> we use the description "org.apache.qpid.application/json") and use this to
> send the string.
> 
> 
> > If content-type isn't the correct place to pass information about the
> > interpretation of the String I'm describing then I'd assume that
> > annotations would be where I should go? Though I have to say that
> > content-type=application/json seems by far and away the most natural place
> > to describe the message content as being JSON.....
> >
> >
> Why not send the "string" as opaque data then?  Basically using content
> type and an AMQP typed value is mixing two different encoding systems...
> Informally clients could probably support it but it's not really the
> intended use case (the spec only says SHOULD - so it's not illegal, just
> strongly discouraged :-) )
> 

The problem with opaque data is that then you really have to set
content-type='application/json; charset=<blah>' and supply your own
unicode codec, which sucks since your friendly AMQP client library will
deal with all that for you if you send an AMQP string message. So I can
understand the desire to say "it's an AMQP string (so AMQP deals with
unicode) but with an extra hint: that string is application/json". You
could invent another property name for the hint but it really feels like
it belongs in content-type.

Of course you have an inconsistency to resolve if somebody sets an AMQP
string body with content-type='application/json; charset="utf-16"'

Could we say: You MAY use content-type with an AMQP string body but it
MUST NOT not have a charset and MUST be ignored by the sender. It MAY be
used as a decoding hint on the receiver.

> -- Rob
> 
> 
> > Frase
> >
> >
> > On 09/09/14 11:31, Rob Godfrey wrote:
> >
> >> Hi Frase,
> >>
> >> ignoring any transformations that may take place in a client library
> >> between setting the content type in the API and what actually goes out on
> >> the wire... the AMQP 1.0 specification defines content-type as follows
> >> (see:
> >> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-
> >> messaging-v1.0-os.html#type-properties
> >> ):
> >>
> >> The RFC-2046 [RFC2046
> >>
> >>> <http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-
> >>> overview-v1.0-os.html#anchor-RFC2046>]
> >>> MIME type for the message's application-data section (body). As per
> >>> RFC-2046 [RFC2046
> >>> <http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-
> >>> overview-v1.0-os.html#anchor-RFC2046>]
> >>> this can contain a charset parameter defining the character encoding
> >>> used:
> >>> e.g., 'text/plain; charset="utf-8"'.
> >>> For clarity, as per section 7.2.1 of RFC-2616 [RFC2616
> >>> <http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-
> >>> overview-v1.0-os.html#anchor-RFC2616>],
> >>> where the content type is unknown the content-type SHOULD NOT be set.
> >>> This
> >>> allows the recipient the opportunity to determine the actual type. Where
> >>> the section is known to be truly opaque binary data, the content-type
> >>> SHOULD be set to application/octet-stream.
> >>> When using an application-data section with a section code other than
> >>> *data*, content-type SHOULD NOT be set.
> >>>
> >>
> >> So, in essence the content type is (only) to be used when the data is
> >> being
> >> sent as an opaque "data" section and in that case it enables the recipient
> >> to interpret the opaque data cofrrectly
> >>
> >> Hope this helps,
> >> Rob
> >>
> >>
> >>
> >> On 8 September 2014 20:01, Fraser Adams <fr...@blueyonder.co.uk>
> >> wrote:
> >>
> >>  Gordon's recent post
> >>>
> >>> When the message is created it looks like this:
> >>>
> >>>       std::string messageContent("example text");
> >>>       qpidMessage.setContentType("text/plain");
> >>>       qpidMessage.setContent(qpid::types::Variant(messageContent));
> >>>
> >>> Use Message::setContentObject() instead and set the encoding, e.g. change
> >>> the last line to:
> >>>
> >>>        qpidMessage.setContentObject(messageContent);
> >>>        qpidMessage.getContentObject().setEncoding("utf8");
> >>>
> >>>
> >>>
> >>> prompted me to ponder about what and what is not the correct use of
> >>> content-type in AMQP 1.0.
> >>>
> >>> So for AMQP 0.10 IIRC in qpid::messaging the content type was used to
> >>> indicate certain AMQP types, for example in particular amqp/list and
> >>> amqp/map now as I understand it for AMQP 1.0 the AMQP type system is
> >>> sufficiently self-describing such that maps/lists/whatever don't need
> >>> such
> >>> things as content-type, however the various APIs do need some mechanism
> >>> to
> >>> specify the relevant type hence (I think) the setContentObject()
> >>> mechanism
> >>> in qpid::messaging
> >>>
> >>> is that correct?
> >>>
> >>>
> >>> Why I ask is that for my JavaScript stuff although I've incorporated a
> >>> mechanism to automagically serialise and deserialise JavaScript Objects
> >>> to
> >>> the AMQP type system I also quite fancy including a mechanism that takes
> >>> a
> >>> JavaScript Object and serialises it as JSON in an AMQP String (obviously
> >>> assuming that it is a data object that is actually convertable to JSON)
> >>> similarly I'd like to be able to receive a JSON object and deserialise it
> >>> into a JavaScript object.
> >>>
> >>> My thinking is that this is actually a good use of the AMQP content-type
> >>> and in this case setting content-type to "application/json" is the right
> >>> thing to do to give the API the right hints to treat Strings as JSON.
> >>>
> >>> Is my logic and understanding of the use of content-type in the AMQP 1.0
> >>> spec. reasonable?
> >>>
> >>> Frase
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >>> For additional commands, e-mail: users-help@qpid.apache.org
> >>>
> >>>
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Use of content-type in AMQP 1.0

[Jakub Scholz <ja...@scholz.cz>]

Interesting discussion. We are using JSON as well as different XML based
standards as well as Google Protocol Buffers in our messages and I would
probably not expect to pack my XML, JSON or GPB data into AMQP String or
AMQP Binary. I would intuitively use / expect it to be as opaque data. I
would always try to avoid mixing the different encoding. One of the
situations where I think it can make life more complicated would be
bridging to other messaging protocols.

Regards
Jakub



On Wed, Sep 10, 2014 at 8:50 PM, Rob Godfrey <ro...@gmail.com>
wrote:

> On 10 September 2014 20:10, Fraser Adams <fr...@blueyonder.co.uk>
> wrote:
>
> > On 10/09/14 17:33, Alan Conway wrote:
> >
> >> On Tue, 2014-09-09 at 20:53 +0200, Rob Godfrey wrote:
> >>
> >>> So - following the logic of the AMQP type system once could suppose
> that
> >>> the intended patern here would be to create a new described type (let's
> >>> say
> >>> we use the description "org.apache.qpid.application/json") and use this
> >>> to
> >>> send the string.
> >>>
> >>>
> >>>  If content-type isn't the correct place to pass information about the
> >>>> interpretation of the String I'm describing then I'd assume that
> >>>> annotations would be where I should go? Though I have to say that
> >>>> content-type=application/json seems by far and away the most natural
> >>>> place
> >>>> to describe the message content as being JSON.....
> >>>>
> >>>>
> >>>>  Why not send the "string" as opaque data then?  Basically using
> content
> >>> type and an AMQP typed value is mixing two different encoding
> systems...
> >>> Informally clients could probably support it but it's not really the
> >>> intended use case (the spec only says SHOULD - so it's not illegal,
> just
> >>> strongly discouraged :-) )
> >>>
> >>>  The problem with opaque data is that then you really have to set
> >> content-type='application/json; charset=<blah>' and supply your own
> >> unicode codec, which sucks since your friendly AMQP client library will
> >> deal with all that for you if you send an AMQP string message. So I can
> >> understand the desire to say "it's an AMQP string (so AMQP deals with
> >> unicode) but with an extra hint: that string is application/json". You
> >> could invent another property name for the hint but it really feels like
> >> it belongs in content-type.
> >>
> >> Of course you have an inconsistency to resolve if somebody sets an AMQP
> >> string body with content-type='application/json; charset="utf-16"'
> >>
> >> Could we say: You MAY use content-type with an AMQP string body but it
> >> MUST NOT not have a charset and MUST be ignored by the sender. It MAY be
> >> used as a decoding hint on the receiver.
> >>
> >>
> >>
> > I have to violently agree with Alan here!!
> >
> > If I'm honest Rob, both of your suggestions seem a bit alien to me. If I
> > were to put on a "humble user" hat I *strongly* suspect that most normal
> > people would intuitively assume an HTTP-like pattern sending a String
> with
> > a content-type of application/json, after all that's what people do when
> > sending JSON via HTTP. Now I know AMQP is not HTTP, but there's an awful
> > lot to be said for sticking with commonly understood idioms.
> >
>
>
> Yes - and the idiom is that the data which a content-type /
> content-enconding is applied to is (without the content-type /
> content-encoding) opaque.  HTTP doesn't send strings - it sends data, which
> you can interpret by knowing the content type / encoding... and - guess
> what - we have the mechanism for doing that in AMQP - it just doesn't
> involve the use of a section type which explicitly states that it contains
> amqp-encoded data.
>
> I'm not saying that it isn't a better choice to use that idiom, just that
> to mix the AMQP types and the HTTP style encoding isn't going to work.  The
> content-type/encoding give you all you need to decode data, to then try to
> apply that to AMQP encoded data doesn't work.
>
> In the general way of things, I think it's reasonable that a receiving
> client might understand that an amqp-value section containing an
> amqp-string coupled with a content-type with no encoding on it can be
> non-ambiguously interpreted... but as a sender of a message I would say you
> should never do that.  You should send your data in a data section, since
> you are providing the encoding / type information in the content-type /
> encoding properties.
>
>
> >
> > Funnily enough we had a similar conversation the other week on the
> subject
> > of erm subject and it would seem that the AMQP 1.0 approach is to model
> it
> > after RFC-822 email subject.
> >
> > On the idea of the Described type that doesn't seem *totally*
> > unreasonable, though I'd say massively less intuitive than
> > content-type=application/json, but why on earth would you use
> > "org.apache.qpid.application/json" surely "application/json" is an IANA
> > registered content type sure the org.apache.qpid adds extra namespacing
> but
> > I doubt it's what anybody would be expecting (and yes I know in that case
> > it's no longer a content type but rather a description but I'd still
> argue
> > that the description should conform to a commonly understood idiom).
> >
>
> The definition of described types is that the descriptor should be a
> reverse domain name.  application/json would not be valid.  org.json would
> be valid (but we don't own it - though I doubt they'd mind if someone asked
> to register it for this purpose).
>
>
> >
> > TBH IMHO anything other that content-type=application/json with the body
> > being a string containing the JSON seems downright weird to me :-)
> >
> >
> Then you could / should use the data section type for your message, not the
> amqp-value section type - you want to convey the semantics associated with
> the value in the MIME style not the AMQP encoding style.
>
> I'm really not expressing a preference over which style one should use - I
> certainly think there is a strong case to be made for the MIME style having
> a greater chance of wider interoperability.  The point I am trying to make
> is that there is (for better or worse) two ways of expressing the encoding
> and semantics of the data being transferred.  Option 1 is to use the AMQP
> type system to encode your data (as an amqp-value or an amqp-sequence).
>  Option 2 is to send the data "opaque" as far as the AMQP type system is
> concerned, but with the information on encoding and semantics in the
> content-type and content-encoding properties fields.
>
>
> > As it happens I actually (de)serialise JavaScript into the AMQP type
> > system, so this idea was kind of a "nice to have" for cases where an
> > application might be sending JSON and I could then simply ask my
> JavaScript
> > client to deserialise it in a nice friendly way, but frankly I'd sooner
> not
> > implement it if it means making people use counterintuitive constructs
> :-(
> >
> >
> As above - I agree that using application/json makes complete sense if you
> want to send / receive the data in the HTTP style - but then don't send
> explicitly AMQP encoded data, use the appropriate section type.  Remember
> that you are not sending "a string" you are sending a section which is
> explicitly an "amqp-value" which can be any form of data encoded in AMQP.
>
> I'm not going to argue that a strong case could be made that it is a
> mistake to offer two different encoding mechanisms.  Certainly for sending
> typed data like maps and lists it is convenient to use the AMQP type
> system, however in retrospect it may have been better to simply offer a
> single mechanism of opaque binary and then define a sensible MIME type for
> this content (which is effectively what previous versions of the protocol
> did, though without formally registering those mime types).
>
> All I'm arguing is that for a given message you should use one encoding
> style only, and that one shouldn't assume that the content-type /
> content-encoding will be any more visible to the end user than the
> descriptor of a described type.
>
> -- Rob
>
>
> >
> > Frase
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>

Re: Use of content-type in AMQP 1.0

[Gordon Sim <gs...@redhat.com>]

On 09/10/2014 07:50 PM, Rob Godfrey wrote:
> one shouldn't assume that the content-type /
> content-encoding will be any more visible to the end user than the
> descriptor of a described type

The content-type is a message property. Message properties are a very 
well understood concept, supported by all previous versions of AMQP as 
well as other protocols and APIs both open and proprietary.

AMQP 1.0 descriptors are pretty specific to that protocol.

So in practice I think content-type will in general be much more likely 
to be visible than descriptors of described types.

Any API that didn't make the content-type accessible in some way would 
be worse off for it. Any system that relied on the exchange of 
descriptors from within an amqp-value section would reduce the 
likelihood of interoperability.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Use of content-type in AMQP 1.0

[Rob Godfrey <ro...@gmail.com>]

On 10 September 2014 20:10, Fraser Adams <fr...@blueyonder.co.uk>
wrote:

> On 10/09/14 17:33, Alan Conway wrote:
>
>> On Tue, 2014-09-09 at 20:53 +0200, Rob Godfrey wrote:
>>
>>> So - following the logic of the AMQP type system once could suppose that
>>> the intended patern here would be to create a new described type (let's
>>> say
>>> we use the description "org.apache.qpid.application/json") and use this
>>> to
>>> send the string.
>>>
>>>
>>>  If content-type isn't the correct place to pass information about the
>>>> interpretation of the String I'm describing then I'd assume that
>>>> annotations would be where I should go? Though I have to say that
>>>> content-type=application/json seems by far and away the most natural
>>>> place
>>>> to describe the message content as being JSON.....
>>>>
>>>>
>>>>  Why not send the "string" as opaque data then?  Basically using content
>>> type and an AMQP typed value is mixing two different encoding systems...
>>> Informally clients could probably support it but it's not really the
>>> intended use case (the spec only says SHOULD - so it's not illegal, just
>>> strongly discouraged :-) )
>>>
>>>  The problem with opaque data is that then you really have to set
>> content-type='application/json; charset=<blah>' and supply your own
>> unicode codec, which sucks since your friendly AMQP client library will
>> deal with all that for you if you send an AMQP string message. So I can
>> understand the desire to say "it's an AMQP string (so AMQP deals with
>> unicode) but with an extra hint: that string is application/json". You
>> could invent another property name for the hint but it really feels like
>> it belongs in content-type.
>>
>> Of course you have an inconsistency to resolve if somebody sets an AMQP
>> string body with content-type='application/json; charset="utf-16"'
>>
>> Could we say: You MAY use content-type with an AMQP string body but it
>> MUST NOT not have a charset and MUST be ignored by the sender. It MAY be
>> used as a decoding hint on the receiver.
>>
>>
>>
> I have to violently agree with Alan here!!
>
> If I'm honest Rob, both of your suggestions seem a bit alien to me. If I
> were to put on a "humble user" hat I *strongly* suspect that most normal
> people would intuitively assume an HTTP-like pattern sending a String with
> a content-type of application/json, after all that's what people do when
> sending JSON via HTTP. Now I know AMQP is not HTTP, but there's an awful
> lot to be said for sticking with commonly understood idioms.
>


Yes - and the idiom is that the data which a content-type /
content-enconding is applied to is (without the content-type /
content-encoding) opaque.  HTTP doesn't send strings - it sends data, which
you can interpret by knowing the content type / encoding... and - guess
what - we have the mechanism for doing that in AMQP - it just doesn't
involve the use of a section type which explicitly states that it contains
amqp-encoded data.

I'm not saying that it isn't a better choice to use that idiom, just that
to mix the AMQP types and the HTTP style encoding isn't going to work.  The
content-type/encoding give you all you need to decode data, to then try to
apply that to AMQP encoded data doesn't work.

In the general way of things, I think it's reasonable that a receiving
client might understand that an amqp-value section containing an
amqp-string coupled with a content-type with no encoding on it can be
non-ambiguously interpreted... but as a sender of a message I would say you
should never do that.  You should send your data in a data section, since
you are providing the encoding / type information in the content-type /
encoding properties.


>
> Funnily enough we had a similar conversation the other week on the subject
> of erm subject and it would seem that the AMQP 1.0 approach is to model it
> after RFC-822 email subject.
>
> On the idea of the Described type that doesn't seem *totally*
> unreasonable, though I'd say massively less intuitive than
> content-type=application/json, but why on earth would you use
> "org.apache.qpid.application/json" surely "application/json" is an IANA
> registered content type sure the org.apache.qpid adds extra namespacing but
> I doubt it's what anybody would be expecting (and yes I know in that case
> it's no longer a content type but rather a description but I'd still argue
> that the description should conform to a commonly understood idiom).
>

The definition of described types is that the descriptor should be a
reverse domain name.  application/json would not be valid.  org.json would
be valid (but we don't own it - though I doubt they'd mind if someone asked
to register it for this purpose).


>
> TBH IMHO anything other that content-type=application/json with the body
> being a string containing the JSON seems downright weird to me :-)
>
>
Then you could / should use the data section type for your message, not the
amqp-value section type - you want to convey the semantics associated with
the value in the MIME style not the AMQP encoding style.

I'm really not expressing a preference over which style one should use - I
certainly think there is a strong case to be made for the MIME style having
a greater chance of wider interoperability.  The point I am trying to make
is that there is (for better or worse) two ways of expressing the encoding
and semantics of the data being transferred.  Option 1 is to use the AMQP
type system to encode your data (as an amqp-value or an amqp-sequence).
 Option 2 is to send the data "opaque" as far as the AMQP type system is
concerned, but with the information on encoding and semantics in the
content-type and content-encoding properties fields.


> As it happens I actually (de)serialise JavaScript into the AMQP type
> system, so this idea was kind of a "nice to have" for cases where an
> application might be sending JSON and I could then simply ask my JavaScript
> client to deserialise it in a nice friendly way, but frankly I'd sooner not
> implement it if it means making people use counterintuitive constructs :-(
>
>
As above - I agree that using application/json makes complete sense if you
want to send / receive the data in the HTTP style - but then don't send
explicitly AMQP encoded data, use the appropriate section type.  Remember
that you are not sending "a string" you are sending a section which is
explicitly an "amqp-value" which can be any form of data encoded in AMQP.

I'm not going to argue that a strong case could be made that it is a
mistake to offer two different encoding mechanisms.  Certainly for sending
typed data like maps and lists it is convenient to use the AMQP type
system, however in retrospect it may have been better to simply offer a
single mechanism of opaque binary and then define a sensible MIME type for
this content (which is effectively what previous versions of the protocol
did, though without formally registering those mime types).

All I'm arguing is that for a given message you should use one encoding
style only, and that one shouldn't assume that the content-type /
content-encoding will be any more visible to the end user than the
descriptor of a described type.

-- Rob


>
> Frase
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Re: Use of content-type in AMQP 1.0

[Fraser Adams <fr...@blueyonder.co.uk>]

On 10/09/14 17:33, Alan Conway wrote:
> On Tue, 2014-09-09 at 20:53 +0200, Rob Godfrey wrote:
>> So - following the logic of the AMQP type system once could suppose that
>> the intended patern here would be to create a new described type (let's say
>> we use the description "org.apache.qpid.application/json") and use this to
>> send the string.
>>
>>
>>> If content-type isn't the correct place to pass information about the
>>> interpretation of the String I'm describing then I'd assume that
>>> annotations would be where I should go? Though I have to say that
>>> content-type=application/json seems by far and away the most natural place
>>> to describe the message content as being JSON.....
>>>
>>>
>> Why not send the "string" as opaque data then?  Basically using content
>> type and an AMQP typed value is mixing two different encoding systems...
>> Informally clients could probably support it but it's not really the
>> intended use case (the spec only says SHOULD - so it's not illegal, just
>> strongly discouraged :-) )
>>
> The problem with opaque data is that then you really have to set
> content-type='application/json; charset=<blah>' and supply your own
> unicode codec, which sucks since your friendly AMQP client library will
> deal with all that for you if you send an AMQP string message. So I can
> understand the desire to say "it's an AMQP string (so AMQP deals with
> unicode) but with an extra hint: that string is application/json". You
> could invent another property name for the hint but it really feels like
> it belongs in content-type.
>
> Of course you have an inconsistency to resolve if somebody sets an AMQP
> string body with content-type='application/json; charset="utf-16"'
>
> Could we say: You MAY use content-type with an AMQP string body but it
> MUST NOT not have a charset and MUST be ignored by the sender. It MAY be
> used as a decoding hint on the receiver.
>
>

I have to violently agree with Alan here!!

If I'm honest Rob, both of your suggestions seem a bit alien to me. If I 
were to put on a "humble user" hat I *strongly* suspect that most normal 
people would intuitively assume an HTTP-like pattern sending a String 
with a content-type of application/json, after all that's what people do 
when sending JSON via HTTP. Now I know AMQP is not HTTP, but there's an 
awful lot to be said for sticking with commonly understood idioms.

Funnily enough we had a similar conversation the other week on the 
subject of erm subject and it would seem that the AMQP 1.0 approach is 
to model it after RFC-822 email subject.

On the idea of the Described type that doesn't seem *totally* 
unreasonable, though I'd say massively less intuitive than 
content-type=application/json, but why on earth would you use 
"org.apache.qpid.application/json" surely "application/json" is an IANA 
registered content type sure the org.apache.qpid adds extra namespacing 
but I doubt it's what anybody would be expecting (and yes I know in that 
case it's no longer a content type but rather a description but I'd 
still argue that the description should conform to a commonly understood 
idiom).

TBH IMHO anything other that content-type=application/json with the body 
being a string containing the JSON seems downright weird to me :-)

As it happens I actually (de)serialise JavaScript into the AMQP type 
system, so this idea was kind of a "nice to have" for cases where an 
application might be sending JSON and I could then simply ask my 
JavaScript client to deserialise it in a nice friendly way, but frankly 
I'd sooner not implement it if it means making people use 
counterintuitive constructs :-(

Frase



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org