On 11/04/14 11:42, Gordon Sim wrote:
On 04/11/2014 10:48 AM, Fraser Adams wrote:
On 11/04/14 09:57, Gordon Sim wrote:
In the spirit of keeping things as simple as possible, how about using
JSON in the body? It is already in widespread use for modelling state
for all sorts of things (including messaging brokers).
I've got some sympathy with that, though TBH I quite like the AMQP Maps
and Lists and those map pretty well to JSON, but with the added benefit
of a type system for stored primitives, so I'm not totally convinced.
Personally I think the type system causes more problems than it
solves. For the purposes of management you really only need strings
and numbers (also arrays and associative arrays). All the extra
'richness' is just more scope for interoperability issues.
That's a fair point - don't I just know it trying to make intelligent
choices mapping numerical types from JavaScript :-) but ultimately
language bindings are going to have to have ways of dealing with that
anyway (unless we completely remove the AMQP 1.0 type system and replace
it with binary + string). In which case as far as I can see it the
problem space probably ought to fit into client side libraries as
opposed to the wire protocol - as said previously a JSON encode/decode
for Java/C++ would be nice, then client code could be written to use
JSON which would provide a decent AMQP mapping and not have any affect
on things that can serialise/deserialise this stuff fairly transparently.
"For the purposes of management you really only need strings and
numbers" might be reasonable, but you don't necessarily need JSON to
enforce this, perhaps the Management Spec being explicit about UTF
strings and double (I guess) for numbers and you can then map pretty
easily to/from JSON from a management perspective.
It's not that I'm arguing against JSON, my comments are more about what
should be transmitted on the wire vice what should be presented to users.
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
