[occi-wg] Vendor Extensions

[Sam Johnston]

On Fri, Apr 17, 2009 at 5:48 AM, Randy Bias <randyb at gogrid.com> wrote:

>    That would be great, but I can envision vendors implementing things in a
> different way initially and as one version 'wins' we can roll that into the
> baseline as the API is iterated over time.
>

We're going to have to evolve fairly quickly and on an ongoing basis I would
say. You've probably already seen that the core is absolutely minimalist,
telling you how to authenticate and interact with the endpoint.

Everything, including what you would think is basic functionality (search,
machine control) is implemented as an extension, and the use of namespaces
throughout (something Richard at EH isn't particularly convinced about) ensures
that these extensions don't have to worry about standing on each others
toes.

Not only does this mean that vendors can write their own extensions (and
extend existing ones with attributes, actuators, etc.), but when we come to
adding more functionality above/below the infrastructure layer we'll just be
talking about writing extension(s).

An example of where this might be useful is $networking_vendor wanting to
manage the underlying fabric. Rather than having them roll something
completely proprietary and have two points of contact with the
infrastructure they can extend OCCI into areas that we aren't particularly
interested in covering (just yet).

Given that working groups tend to have "start" and "end" points we'll have
to look at setting up something like an attribute registry with e.g. IANA
(see the Atom link
relations<http://www.iana.org/assignments/link-relations/link-relations.xhtml>for
example). This is a great way to play nice with other standards
efforts
too.

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090417/0d377fda/attachment.html