To that point I'd ask - If we're talking about meta-data that infers there is some data to accompany it. Where are the examples of this data? This would help in forming the full picture. Andy -----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Alexis Richardson Sent: 20 October 2009 09:49 To: Sam Johnston Cc: Tim Bray; occi-wg@ogf.org Subject: Re: [occi-wg] confusion about status of link / headers Sam, Please don't throw around words like "bunk" willy nilly. I have just had a look at http://www.rackspacecloud.com/cloud_hosting_products/servers/api I can see some limited use of headers for metadata in a few places. That's never been controversial. But the understanding that I have of your proposal is to use headers wholesale for all metadata. Rackspace don't appear to do that, unless I have misunderstood their document. I also may have misunderstood your proposal. If nobody understands your proposal except you, then it will not be possible to gain consensus around it. Are you saying "OCCI metadata should be more like Rackspace metadata"? alexis On Tue, Oct 20, 2009 at 9:07 AM, Sam Johnston <samj@samj.net> wrote:
On Tue, Oct 20, 2009 at 9:55 AM, Alexis Richardson <alexis.richardson@gmail.com> wrote:
What about compute clouds?
Rackspace Cloud API for a start:
HTTP/1.1 204 No Content Date: Mon, 12 Nov 2007 15:32:21 GMT Server: Apache X-Server-Management-Url: https://servers.api.rackspacecloud.com/v1.0/35428 X-Storage-Url: https://storage.clouddrive.com/v1/CloudFS_9c83b-5ed4 X-CDN-Management-Url: https://cdn.clouddrive.com/v1/CloudFS_9c83b-5ed4 X-Auth-Token: eaaafd18-0fed-4b3a-81b4-663c99ec1cbb Content-Length: 0 Content-Type: text/plain; charset=UTF-8
Microsoft Azure uses headers for "attributes" as well, in the same way as I had originally proposed:
x-ms-meta-name: value Returns a metadata value for the container.
However prefer that the header names are static/opaque rather than using a template and parsing them:
Attribute: name=value
This to me is cleaner and more self-explanatory, plus it is easily collapsed ala:
Attribute: name1=value1, name2=value2, ... namen=valuen
Anyway suffice to say that claims this is somehow "experimental" are bunk.
Sam
On Tue, Oct 20, 2009 at 6:19 AM, Adrian Cole <adrian@jclouds.org> wrote:
Here are options for metadata used in some of the major storage clouds FWIW:
S3, Rackspace, EMC Atmos, Azure - Headers Nirvanix - query params in, xml entity out Mezeo - entity
Of the ones using headers, S3, Rackspace and Azure use prefix with values stored as-us. Atmos joins all metadata together into one header, making parsing trivial (split /,/), but necessary.
The most expensive option of the above is entity, where each metadata value is a separate GET. However, entities allow binary metadata and zero restrictions on it, which may be useful.
In jclouds, we time parsing of response values. A simple XML doc with only several elements written in SAX takes a few ms to parse. My log files are not precise enough to find the overhead in parsing headers: they always start and finish within the same millisecond.
I hope this background helps, and also helps explain why I'm vocal on such topics such as headers vs entities :)
Cheers, -Adrian
On Mon, Oct 19, 2009 at 4:21 PM, Sam Johnston <samj@samj.net> wrote:
On Tue, Oct 20, 2009 at 12:57 AM, gary mazzaferro <garymazzaferro@gmail.com> wrote:
The http header and key/value pairs need to parsed also, there is no free ride here.
Every HTTP library I have ever used parses HTTP headers and puts them in a nice hash for you ready to consume. If we go for "Name: Value" then that's all there is to it. If we go for "Attribute: name=value" as is currently proposed (which is arguably cleaner, follows cookies' "prior art" and avoids Amazon's prefix hack) then you just have to split on '='.
To illustrate how clean this is by example:
#!/usr/bin/python import urllib2 response = urllib2.urlopen('http://cloud.example.com/myvm') representation = response.read() metadata = response.info() print metadata['occi-compute-cores']
As soon as you start talking about payloads you have to fire up a parser (JSON/XML/Atom/etc.) or write your own (previous text rendering) which is significantly more work to do at both design and run times. Not to mention more work for us to do now and more scope for interoperability problems.
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.