On Fri, Apr 11, 2014 at 12:54 PM, Gordon Sim <[email protected]> wrote:
> 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. My point is that types are fundamental to a given problem domain. If your application needs to represent timestamps, then you're going to figure out a way to do that whether or not your encoding system permits you do to it in a standard way, and that is ultimately the source of conversion/comparison issues. It's like the original XML myth that if everything uses XML, data interchange is magically easy somehow. Anyone who's seen the number of different ways people represent addresses in XML knows that this is utterly false. 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! > > > 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? > That's really up to whoever is defining the application. The AMQP type system is really just about encoding the data, it intentionally doesn't mandate how you interpret/convert/cast/coerce it in your application. As a general principal for building robust systems I would recommend following Postel's law here[1]. "Be conservative in what you send, and be liberal in what you accept." So I'd say you should send the value as uint8, but accept any integral value in the appropriate range. [1] http://en.wikipedia.org/wiki/Robustness_principle > > 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. > 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. > > 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 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. > > [...] > > 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. So how would you propose dealing with things like creation/expiration dates and message ttls using JSON? --Rafael
