[occi-wg] confusion about status of link / headers

[Alexis Richardson]

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 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
> 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 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
>> >
>
>