On 04/11/2014 05:06 PM, Rafael Schloming wrote:
I don't think an encoding system actually has any impact at all on type conversion/comparison issues.
I think it does. An encoding system that can encode 8 as many different types increases the chance that a given system gets it in a type it wasn't expecting.
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.
Lets say I want to define the number of recognised priority levels for a queue, the valid values for which will be 0 to 100 inclusive. What should the type of that be? Lets say I choose to define it as a uint8.
Is it then illegal to send a legal value encoded as e.g. an int8 or a uint16?
I would argue not. I would argue that the real 'intended type' is an integer value between 0 and 100 and the exact encoding in which it is sent isn't that important. However when the encoding presents lots of options its more likely that two parts of a system didn't pick the same option and further that one did not anticipate the choice of the other.
Can one work around this? Of course! One can also work around the issues with dates/times in JSON. No system will be completely free from annoyances or problems.
[...]
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'm sure there are cases for which it is overly simple. However I personally don't think managing brokers and similar things is one of those, and I think using a simpler type system and encoding would make it more accessible and easier to adopt.
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
