[occi-wg] confusion about status of link / headers
andrewx.edmonds at intel.com
Tue Oct 20 05:28:45 CDT 2009
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.
From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On Behalf Of Alexis Richardson
Sent: 20 October 2009 09:49
To: Sam Johnston
Cc: Tim Bray; occi-wg at ogf.org
Subject: Re: [occi-wg] confusion about status of link / headers
Please don't throw around words like "bunk" willy nilly.
I have just had a look at
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"?
On Tue, Oct 20, 2009 at 9:07 AM, Sam Johnston <samj at samj.net> wrote:
> On Tue, Oct 20, 2009 at 9:55 AM, Alexis Richardson
> <alexis.richardson at 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
>> Attribute: name1=value1, name2=value2, ... namen=valuen
> Anyway suffice to say that claims this is somehow "experimental" are bunk.
>> On Tue, Oct 20, 2009 at 6:19 AM, Adrian Cole <adrian at 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 at samj.net> wrote:
>> >> On Tue, Oct 20, 2009 at 12:57 AM, gary mazzaferro
>> >> <garymazzaferro at 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 at ogf.org
>> >> http://www.ogf.org/mailman/listinfo/occi-wg
>> > _______________________________________________
>> > occi-wg mailing list
>> > occi-wg at ogf.org
>> > http://www.ogf.org/mailman/listinfo/occi-wg
occi-wg mailing list
occi-wg at ogf.org
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.
More information about the occi-wg