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.
[...]
"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.
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)?
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
