[occi-wg] Simple JSON rendering for OCCI

[Sam Johnston]

On Thu, May 14, 2009 at 9:01 PM, Alexis Richardson <
alexis.richardson at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090514/99dfb103/attachment.html