On Thu, May 14, 2009 at 9:01 PM, Alexis Richardson < alexis.richardson@gmail.com> wrote:
I am not arguing against extensions, I am arguing that dealing with them needs to be done so as to not make it easy to break interop.
We're arguing for the same thing then. Good.
The reason that extensibility is the enemy of interoperability is that if two users extend the core protocol then:
1. If they do not interoperate then this is really hard to debug without appealing to the users who made them. "Really hard" meaning "impractical to the point of hampering adoption".
2. If they appear to interoperate then we still cannot tell if they are actually interoperating because the semantics of their extensions may not be the same.
Whoever said extensions need to be interoperable? We can do what we can (e.g. registries) but beyond that extensions are just somewhere for people to put stuff, like trunk space. If we missed it and we need it we can add it in a revision (and I'm not thinking infrequent major revisions like 1.0 vs 2.0, rather regular addition of extensions to cover needs in order of priority). If OCCI core (sans resources) never needed to change I'd be happy, which means it should be really minimalistic and very extensible. A good specification explicitly deals with extensibility (assuming it is desired) - Atom has an entire section on Extending Atom<http://tools.ietf.org/html/rfc4287#section-6>the gist of which is: * *
*Atom Processors that encounter foreign markup in a location that is legal according to this specification MUST NOT stop processing or signal an error. It might be the case that the Atom Processor is able to process the foreign markup correctly and does so. Otherwise, such markup is termed "unknown foreign markup".*
Basically, if you don't know what it does then don't touch it.
But, users want extensions. The solution to this problem is to allow extensions but not require them to be in the core protocol. Not being in the core protocol, means being on the 'edge', which is an appropriate term for 'not core' or 'at the edge of the network' to be more specific.
I'm happy to have nothing in the core protocol *except* extensibility... think the microkernel approach to standards development. That's not a bad analogy actually, only all the things that make it not work for operating systems (e.g. context switching costs) don't apply here. Andy's alternative is more like a monolithic kernel and we all know what happens when you try to poke a broken driver into one of those. This approach is actually necessary if we want to support hypervisor-only setups (e.g. core + compute), nas/san (core + storate) and network devices (core + network).
Does TCP have extensions? No. (Or if it does people apparently don't use them because it would break interop)
Actually yes it does but they don't work properly because of broken, non-compliant middleware (think ECN). You can read a Google paper on Probing the viability of TCP extensions<http://www.imperialviolet.org/binary/ecntest.pdf>for more details but it boils down to: *TCP was designed with extendibility in mind, chiefly reflected in the
options mechanism. However, there have beenrepeated observations of misbehaving middleware that have hampered the deployment of beneficial TCP extensions*
Extensibility now doesn't work so TCP's users pay (in expensive workarounds, reduced functionality/performat, etc.). Does WS-* have extensions? Yes.
It wasn't WS-*'s extensibility that killed it. If we act like we're operating in a vacuum then we'll have exactly the same result.
Please - anyone - tell me what is wrong with the above argument.
I just have. Not only that but it relies on the premise that I'm promoting putting extensibility where it can interfere with the interoperability components (I'm not).
Sam, I liked Gary's diagrams - perhaps you did too which suggests some common ground or that we are arguing at cross purposes?
Gary's diagrams were interesting but didn't get much of a rise out of me - adapters aren't particularly performant and someone has to write code which is exactly my problem with JSON... all of these problems (like everything) are fixable depending on how much code you want to write. XML adapters don't require coding (unless you call stylesheets coding). Sam