Not at all, you’re right – it would be very helpful.
Lori
From: Sam Johnston
[mailto:samj@samj.net]
Sent: Thursday, January 21, 2010 8:45 AM
To: Lori Mac Vittie
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@samj.net> wrote:
On Thu, Jan 21, 2010 at 9:05 AM, Lori Mac Vittie <L.MacVittie@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@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Sam Johnston
Sent: Wednesday, January 20, 2010 7:31 AM
To: Mike Kelly
Cc: occi-wg@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 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@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]:).
SamOn Fri, Jan 8, 2010 at 8:23 PM, Mike Kelly <mike@mykanjo.co.uk <mailto:mike@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 listocci-wg@ogf.org <mailto:occi-wg@ogf.org>