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
Frase
