On 11 April 2014 11:48, Fraser Adams <[email protected]> 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.
>
> 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.
>
>
>
Yeah - if we went with JSON we'd also have to define a canonical encoding
of all AMQP types into JSON which we've looked at before and doesn't end up
pretty... And it would make things harder for JMS users, etc... I think
the way to go is for client libraries to have JSON -> AMQP Map translation
which hopefully we can then turn into a canonical AMQP <-> JSON mapping
which we can push through as a standard
> 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 :-)
>
Yeah - we can do that... we should probably use a different font face or
something when we talk about AMQP types "string" rather than using it as a
common word
-- Rob
>
> Cheers,
> Frase
>
>
>
>
>
>
