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

[Sam Johnston]

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<http://msdn.microsoft.com/en-us/library/dd179350.aspx>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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20091020/d745af48/attachment.html