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

[Alexis Richardson]

What about compute clouds?

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
>