<rant> The problem with JSON is that it has achieved "ease and simplicity" by arguably over constraining the types of values it can represent. There is a bit of a false promise in the whole "look every language knows about numbers and strings, so every language can deal with JSON" premise of the whole thing. That's great and all, but almost no real world applications can function purely on numbers and strings and so if your application needs say timestamps and/or binary data, then you suddenly your standard encoding is less of a standard and more just a style of using strings that has to be extended to be able to truly represent values in pretty much any real world domain. Just look at some of the fun people have trying to stuff timestamps into JSON[1], or dealing with binary data[2]:
[1] http://markembling.info/2011/07/json-date-time [2] http://stackoverflow.com/questions/1443158/binary-data-in-json-string-something-better-than-base64 These sorts of problems have already motivated things like BSON and UBJSON both of which add a significant number of types and I think also add the ability to extend the type system and in fact use the same type/length/data encoding format that AMQP does. Despite their motivation by JSON they actually resemble the AMQP type system far more than they resemble JSON. </rant> (As an aside, don't let the XML rant tags mislead you, I'm no fan of XML either.) Further possibly less ranty comments inline... On Fri, Apr 11, 2014 at 11:34 AM, Gordon Sim <[email protected]> wrote: > 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. I don't think an encoding system actually has any impact at all on type conversion/comparison issues. That's really a function of the language at a given endpoint. The best you can do with a type system is provide a means for the author of a given piece of content to fully express the intended types in a standard way. If you happen to be decoding into a language that can't easily express all the different types then so be it, but that doesn't mean there shouldn't be a standard way of expressing what are ultimately all very commonly used and well understood types. Look at trying to compare date/time values in JSON vs AMQP. If the language you've decoded your values into doesn't have a standard representation of date/time values then you're equally screwed either way. If it does have a standard representation then at least in the AMQP case you don't have any 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. I think the real question here is can you get away without a standard means of representing things like timestamps and/or ttls. > > > 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. I tend to think JSON is very popular exactly because it is a reaction to certain overcomplicated technologies, but as often happens in reactionary situations like that it really does go a bit to far in the overly simplistic direction. I think with things like BSON/UBJSON/etc, and even with AMQP's type system itself you see the pendulum swinging back hopefully towards a reasonable middle ground. --Rafael
