[occi-wg] Fwd: Categorization via link relations
Sam Johnston
samj at samj.net
Thu Jan 21 10:52:42 CST 2010
Morning all,
The following off-list discussion ought to shed some light on the
relationship between metadata (properties, categories, links) and
representations... hopefully it will answer more questions than is raises!
Sam
---------- Forwarded message ----------
From: Lori Mac Vittie <L.MacVittie at f5.com>
Date: Thu, Jan 21, 2010 at 11:46 AM
Subject: RE: [occi-wg] Categorization via link relations
To: Sam Johnston <samj at samj.net>
Not at all, you’re right – it would be very helpful.
Lori
*From:* Sam Johnston [mailto:samj at samj.net]
*Sent:* Thursday, January 21, 2010 8:45 AM
*To:* Lori Mac Vittie
*Subject:* Re: [occi-wg] Categorization via link relations
Lori,
Forgot to ask - this explanation would be very useful to others - do you
mind if I copy it to the list?
Sam
On Thu, Jan 21, 2010 at 11:12 AM, Sam Johnston <samj at samj.net> wrote:
On Thu, Jan 21, 2010 at 9:05 AM, Lori Mac Vittie <L.MacVittie at f5.com> wrote:
Sam,
I’ve been digging in a bit deeper into the OCCI spec as it sits and was
wondering what you think is the proper mechanism for extending the “network”
resource to include more infrastructure concepts.
So there are basically two ways: in-band and out-of-band. That is, you can
define your own representation identified by MIME type - this is what we do
with OVF. Or you can create properties/categories/links (e.g. compute.cores)
For example, a large class of network resources can be classified as a
“proxy” (either transparent or inline). Proxies include the notion of
network as they’re currently defined, so I was thinking given your current
nomenclature it would be “occi.network.proxy”. “Proxy” would need to
encapsulate a type, probably an ENUM representing one of “firewall,
loadbalancer, cache” etc… There are quite a few in this category as almost
every piece of infrastructure can technically be classified as some sort of
proxy.
I would use a category for this - perhaps a global "device type" category
which could be router, switch, proxy, load balancer, etc. (and of course
multiple values would be allowed). The actual configuration itself - say a
squid config file - would either be linked (as it essentially describes the
resource... could use the existing "describedby" relation or create a new
one) or could be an actual representation (e.g. you could GET the resource
directly in application/vnd.squid-conf or similar).
What I’m having trouble with is that it would make sense to reuse the
“network” definition down the hierarchy because every “proxy” has associated
with it multiple “networks” (usually). At a minimum you’re usually defining
at least one “management network” and in the case of an inline configuration
one “public network” (the one which is the actual endpoint for the service
provided.
Any resource can have LINKs to other resources so arbitrarily complex
networks can be modelled easily.
I am unclear whether it would make sense to define
“occi.network.proxy.firewall” or to leave the “type” as an attribute of
“occi.network.proxy”. What is the process you use to decide? I’m also not
entirely certain that “proxy” is the right noun, but it **feels** right as
it’s a broad description (and accurate abstraction) of the entire class of
devices.
Where you have the urge to use an enum you probably want to consider
categories. For example you could request all load balancers in the US east
coast with a request like "GET /-/us-east/loadbalancer".
Sam
*From:* occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] *On
Behalf Of *Sam Johnston
*Sent:* Wednesday, January 20, 2010 7:31 AM
*To:* Mike Kelly
*Cc:* occi-wg at ogf.org
*Subject:* Re: [occi-wg] Categorization via link relations
Mike,
This was mentioned on the call today (during which I was unable to speak
despite calling in twice - presumably something at my end) and I definitely
agree with Alexis in that we shouldn't create new technology where we don't
absolutely have to. I wrote the Web
Categories<http://tools.ietf.org/html/draft-johnston-http-category-header-00>Internet-Draft
for OCCI because there didn't appear to be any existing
mechanism for this, but eventually came to the realisation (like you) that
it would be possible to convey this information via the Link: header. What's
possible and what's sensible aren't always the same thing though and I'd
argue that there's not much difference in terms of handling effort as you'll
most likely be dealing with raw headers anyway (remember we need schemes so
even if there was some intelligence to the handling of links we'd have to
bypass it for this).
A greater concern for me is the handling of properties/attributes. Rather
than give people carte blanche in terms of encouraging them to mint their
own headers for each additional property, I think it makes a lot more sense
to have e.g. a "Property" header which acts like a kind of server-side
cookie (and is modelled after Set-Cookie[2]). This is what is currently
documented and all the examples I've thrown at it all work nicely thus far.
Sam
On Sat, Jan 16, 2010 at 8:53 AM, Mike Kelly <mike at mykanjo.co.uk> wrote:
Hi Sam,
A reason for sticking to Link headers could be to keep 'consistency' in the
protocol's hypertext mechanisms? Another reason is that tools for handling
Link headers, client and server side, are likely to have broader
availability.
Cheers,
Mike
Sam Johnston wrote:
Mike,
Thanks for taking the time to look at our specifications. The categories are
dealt with in a separate IETF Internet-Draft (
http://tools.ietf.org/html/draft-johnston-http-category-header-00) but it's
true that they could be layered on top of the Link: header. I hadn't
considered this option at the time but it does make some sense. OTOH we need
to sensibly layer properties/attributes on top of HTTP headers so we'll
probably be blazing our own trail there anyway (using Property:/Attribute:
headers modelled after Set-Cookie[2]:).
Sam
On Fri, Jan 8, 2010 at 8:23 PM, Mike Kelly <mike at mykanjo.co.uk <mailto:
mike at mykanjo.co.uk>> wrote:
I really like the protocol, you've done a great job
I have a question: Why is Category given a unique header, and not
simply
treated as another type of link relation for a resource?
i.e.
Category: compute;
scheme="http://purl.org/occi/kind/";
label="Compute Resource"
.. could that actually be written as:
Link: <http://occi.org/kinds/compute>;
rel=<http://purl.org/occi/kind>;
title="Compute Resource"
Cheers,
Mike
_______________________________________________
occi-wg mailing list
occi-wg at ogf.org <mailto:occi-wg at ogf.org>
http://www.ogf.org/mailman/listinfo/occi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20100121/f342c92e/attachment.html
More information about the occi-wg
mailing list