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.
If I'm really honest (and I've said this before so it won't be any
surprise) the best thing that could be done to simplify things from a
Java perspective it to use ObjectMessage to encode java.util.List and
java.util.Map. Being able to use standard containers and manipulation
thereof makes most of the pain go away, so I'm not convinced that the
extra encoding/decoding step into a JSON string is the right thing and
feels more of a cop-out/workaround
Another thing (and this might be moot in the context of the Management
Spec) is that it's not totally unreasonable to want to put binary data
into a Map - one of the things I experimented with a while back was the
possibility of using QMF method invocation as a "standardised" (I wish)
AMQP based remote method invocation framework. It actually had
everything I needed including a documented specification, mechanisms for
schema distribution - the works. I still think it was quite neat and
would have saved a ton of wheel reinvention. Anyway I used that to
retrieve large binary payloads as part of an experiment - you could of
course achieve this plenty of other ways, but as I say not having a
mechanism for binary contents is perhaps an unnecessary constraint on
users?
Ironically I've got a feeling using JSON actually *complicates* things
for many users. As you probably know I'm working on "productising"
JavaScript bindings to Proton Messenger this works in a very similar way
to the Python bindings where I can do something like:
message.setAddress(address);
message.setSubject(subject);
message.body = ['Rod', 'Jane', 'Freddy', {cat: true, donkey: 'hee
haw'}];
messenger.put(message);
So I can transparently serialise native JavaScript Arrays to AMQP list
and Object to AMQP map.
I'm quite looking forward to getting it finished so that I can mess
around with AMQP 1.0 Management in the most enjoyable way possible. I'm
not too keen on an extra JSON encoding/parsing step :-) though I could
(and would) clearly hide it in my put implementation.
My personal take on this is that using JSON might be nice from a client
perspective but that the best way to achieve that might be to add a JSON
encode/decode capability to the C++/Java tool sets and use AMQP maps and
lists on the wire so languages that can handle these things nicely
aren't penalised.
FWIW I suggested using Maps in the Management spec. because it was still
in draft so figured it might be easier to stop that nobbling Java than
to get Java to behave more sensibly :-D
While I'm on a roll...
Rob, could you do me a favour and make sure that the Management spec is
*absolutely clear and explicit* (referring to the relevant section in
the AMQP 1.0 spec would be good) that strings in management nodes and
manageable entities should be AMQP 1.0 UTF8 strings. I realise that it's
implicit in some of the wording, but I'm in no hurry to allow the
possibility that management nodes (or clients) might be sending C style
binary strings. I've been on the receiving end of too many
ClassCastExceptions of byte[] values in maps when I was reasonably
expecting String. I'd really like to be able to say that an application
is off spec if it sends binary strings and be able to clearly point to a
reference to say so #interoperability :-)
Cheers,
Frase
