On 04/11/2014 02:58 PM, Fraser Adams wrote:
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'}]);
I don't think you would need to do that. For example, you could allow
the application to leave the body as a map and e.g. set a content-type
to text/json and then have the library encode it under the covers.
The point I was making is that a client library that supports AMQP, may
still required the body of messages to be encoded/decoded by the
application. That may not be about the language it is written in, but
the API exposed.
(This for example was how the c++ qpid::messaging API was designed to
work originally; the API had to be extended to support AMQP 1.0 encoded
messages).
Using such a library requires you to have access to codecs for whatever
encoding, or to create one yourself. That is where the advantage of
something simple comes in.
[...]
I do generally have a lot of time for JSON, but I guess I just don't
really see what it buys here,
I think it generally makes things more accessible by virtue of being a
simpler encoding, and minimises the scope for type conversion and
comparison issues.
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.
It's better - in my opinion of course - because its simpler and far more
widely used.
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.
In a modified version of your original code snippet:
message.body = ['Rod', 10000001, {cat: true, donkey: 8}];
how would you indicate that this is a management related message and
that therefore the numbers should always be encoded as a double? (and
what about the boolean?)
If you have a way to indicate the encoding to use, that same approach
could be used to encode as JSON or anything else.
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.
As above, I don't think you need to do that.
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 certainly don't care about that aspect.
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.
I see JSON as a simpler encoding rather than a hack that pushes
everything around as a string. So to me, its a shame to use a more
complex encoding when you don't need it.
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 a pain in JMS, not Java per se, a different API might have no
issue). JSON isn't a way of ducking that specific issue. To me its a
generalisation of the notion of making things simple (i.e. avoiding
making this more complicated than they need to be) for as wide a set of
usages as possible.
It's probably a bit moot though I guess
More than likely :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
