On 04/11/2014 06:36 PM, Rafael Schloming wrote:
JSON makes exactly the same sort of vacuous promise. By magically limiting everyone to use only strings and numbers, then structured data exchange suddenly becomes trivial!
Be as dismissive as you like. The fact remains that *many* systems today manage perfectly well with JSON, with all its imperfections.
No, it doesn't make data exchange trivial. But then I don't believe the AMQP type system does either.
There really isn't nearly as much room for this sort of thing as you're suggesting. If you allow for the automatic type conversions between numeric types that most languages do automatically, then the number of different choices you have for "intended types" is actually quite constrained.
I have first hand - though possibly vacuous - experience of bugs with these sorts of conversions and comparisons.
[...]
I don't think this is a valid comparison. There is exactly one way to "work around" the issue in the AMQP case, your implementation simply needs to do pretty much the same standard type conversions that most languages do automatically. In the case of dates/times with JSON there are a hundred different and non interoperable ways to "work around" the problem.
We will have to agree to disagree. [...]
So how would you propose dealing with things like creation/expiration dates and message ttls using JSON?
I would probably lean towards a string format for creation/expiration dates (i.e. absolute times) and a numeric values representing milliseconds for ttls and relative times. Ultimately though it would be about reaching a consensus with as wide a range of implementers as possible, in the context of some more specific, concrete schema alignments.
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
