qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Comments on the AMQP management spec
Date Fri, 11 Apr 2014 13:58:54 GMT
On 11/04/14 13:25, Gordon Sim wrote:
> On 04/11/2014 12:31 PM, Fraser Adams wrote:
>> ultimately language bindings are going to have to have ways of
>> dealing with that anyway
> True, but there is a difference between the library having the ability 
> to encode/decode the type system internally and exposing that in a 
> suitable manner to the applications.

That was exactly the point I was making earlier "exposing that in a 
suitable manner to the applications." in the JavaScript example I 
illustrated earlier it's currently *exactly* in a manner suitable to the 
application and I guess python is largely the same it's only really 
strongly typed languages like C++ and Java where it gets more excitings.

It wouldn't totally /kill/ me to JSON.stringify:
message.body = JSON.stringify(['Rod', 'Jane', 'Freddy', {cat: true, 
donkey: 'hee haw'}]);

but TBH I think that it's C++ and Java that are the cause of the problem 
:-) so why force ugly code onto pretty languages like Python and JavaScript.

> [...]
>> "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.
> I certainly agree you don't *need* JSON. However its a well understood 
> and reasonably well supported scheme that is already widely used for 
> managing resources.
I do generally have a lot of time for JSON, but I guess I just don't 
really see what it buys here, ultimately C++ and Java clients will 
likely have application code using Maps and Lists so will need a 
mechanism to serialise into JSON - so ultimately it's just being used as 
a serialised wire-level format at and that fact would/could probably be 
opaque to users of the Management Spec. but why is that better than AMQP 
Maps and Lists. I'd tend to agree about the limited type system, but as 
I said in my earlier post specifying management node/entity strings as 
AMQP 1.0 String and numbers as AMQP 1.0 double would be enough to 
constrain the type system to something universal and each to convert to 
JSON if needed somewhere else.

> A restricted subset of the AMQP type system would be better than 
> nothing (lest described types start appearing in 'standard' management 
> schemas!), but what's the value of that over just using something that 
> already exists and is simpler (yet sufficient)?
One bit of value is that I don't have to see JSON.stringify() upsetting 
my nice Arrays and Objects ;-) to be fair in my case it's all "mentally" 
JSON anyway so it really is just about the wire format.

I guess that one possible advantage of JSON is that having a simple 
string message body *may* be more compact than AMQP list/map though 
that's probably a marginal benefit, if at all.

I'm still concerned about what would happen if I happened to want to 
create a Management Node or Manageable Entity where I happened to want 
to send it binary data, it might be an edge case and I've not got a good 
use case off the top of my head, using AMQP maps/lists I'd have that 
option, but not with JSON (well base64 bleughhh!!).

It's not something I'm going to die in a ditch over, as I say I'm 
generally quite fond of JSON (as it happens the QMF2 REST API actually 
serialises the QMF Management Objects to JSON so it looks almost exactly 
like you are suggesting in my HTTP responses) but in that case there 
were fewer options - I don't need to do that when I can talk AMQP 
directly it seems a shame pushing things all into a string if you don't 
have to.

To be fair though lists are a right pain in Java, but I think that the 
right answer is to put an place a /nice/ way of encoding/decoding lists 
(ObjectMessage :-)) rather than duck the issue and push strings around.

It's probably a bit moot though I guess that this conversation should go 
much wider than this list as it's really an OASIS discussion and I guess 
that adds a whole world of different vendors into the mix :-) trying to 
herd the cats into agreeing to JSON would probably push the Management 
Spec back about two years ;-D


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message