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

Sam Johnston samj at samj.net
Tue Oct 20 11:56:01 CDT 2009 

Adrian,

We don't vote... we discuss our way to consensus and escalate if we
fail.

Anyway I've had enough for one day/lifetime and I've got a house full
of furniture to build tonight. I do wonder how many people here have
actually bothered to read the spec and understand the issues though -
if you haven't already then please do so now and speak up if anything
doesn't make sense.

Sent from my iPhone

On 20/10/2009, at 18:44, Adrian Cole <adrian at jclouds.org> wrote:

> As we aren't introducing new information, I think we are at a point
> where a vote can take place.  This issue isn't infinitely complex, and
> reasonable to model in choices.  OCCI desires to be a community
> process, so let's see where we fall on this.
>
> Do you agree?
> -Adrian
>
> On Tue, Oct 20, 2009 at 9:39 AM, Alexis Richardson
> <alexis.richardson at gmail.com> wrote:
>> Sam,
>>
>> On Tue, Oct 20, 2009 at 5:31 PM, Sam Johnston <samj at samj.net> wrote:
>>> Alexis,
>>>
>>> Sweeping, unjustified statements are intensely frustrating, not to
>>> mention unhelpful in the absence of a coherent alternative. If
>>> people
>>> choose not to disclose conflicts I happen to be aware of then you
>>> bet
>>> I'll disclose them for them - nothing personal about it.
>>
>> I don't know what 'conflicts' you are referring to, or how these
>> relate to the matter at hand.  If by 'sweeping, unjustified' you
>> refer
>> to the word 'unprecedented' then I shall justify it by pointing out
>> that - at least as I currently understand it - you are proposing use
>> of headers to a *greater* extent than has been done before and to
>> cover a *greater* set of use cases.
>>
>>
>>> Cutting to the chase, both Microsoft and Amazon are using headers
>>> for
>>> metadata to the same extent as what has been proposed.
>>
>> Really - to the "same" extent?  That seems contrary to what has been
>> asserted on this thread previously.
>>
>>
>>> What premature optimisation? *Not* using XML? Do we really need to
>>> drag that carcass out again? Surely Adrian's performance tests put
>>> the
>>> last nail in that particular coffin.
>>
>> Premature optimisation = making performance a critical design concern
>> when we want an API.
>>
>> I have noted Adrian's points as have others.
>>
>>
>>> The question really is about whether we want to be an interface/
>>> protocol like HTTP or some mongrel hybrid of that along with a set
>>> of
>>> XML, JSON and/or text formats for everything we ever intend to model
>>> (knowing that work has already been done by others).
>>
>> Work that has been done by others and shown to work, is a good thing.
>>
>> alexis
>>
>>
>>
>>
>>> Sent from my iPhone
>>>
>>> On 20/10/2009, at 18:10, Alexis Richardson
>>> <alexis.richardson at gmail.com> wrote:
>>>
>>>> Sam
>>>>
>>>> Cut the personal stuff please.
>>>>
>>>> Re 'unproven', I think the issues people are having are:
>>>>
>>>> * The extent, scope and purpose of your application of headers to
>>>> metadata is unprecedented - as I understand it.  Nobody is saying
>>>> it
>>>> has not been done in other and restricted cases.
>>>>
>>>> * Premature optimisation.
>>>>
>>>> alexis
>>>>
>>>>
>>>>
>>>> On Tue, Oct 20, 2009 at 4:44 PM, Sam Johnston <samj at samj.net>
>>>> wrote:
>>>>> Gary,
>>>>>
>>>>> Please be specific with your objections so as I can have some
>>>>> hope of
>>>>> answering them... "several other emails" does not suffice as to
>>>>> the
>>>>> best of my knowledge there are no outstanding issues that I have
>>>>> not
>>>>> comprehensively and convincingly dealt with.
>>>>>
>>>>> Your repeated assertions than HTTP headers are... what is it
>>>>> now...
>>>>> "unproven"... are demonstrably unfounded (refer to the various
>>>>> cloud
>>>>> APIs referred to by myself and Adrian, including both MS Azure and
>>>>> Amazon S3, as well as the history of the Internet in general) and
>>>>> given the frequency, bordering on FUD.
>>>>>
>>>>> Regarding performance, OCCI should strive to be as efficient as
>>>>> possible as it primarily targets public cloud providers who
>>>>> operate
>>>>> at
>>>>> arbitrarily large "cloud" scale. The existing specification is
>>>>> *extremely* efficient and alternatives would at least want to be
>>>>> in
>>>>> the same neighbourhood. Efficiency may be an inconvenient factor
>>>>> for
>>>>> whatever your alternative is, but it's critical for many of our
>>>>> use
>>>>> cases.
>>>>>
>>>>> Finally, you reject OVF without providing any alternative beyond
>>>>> building a replacement from scratch ourselves, after our second
>>>>> and
>>>>> final deadline has just sailed by no less. Have you considered the
>>>>> implementation cost of this? And in the same breath you accuse my
>>>>> proposal of being "unproven"? Give me a break...
>>>>>
>>>>> Correct me if I'm wrong but the way I see it is that you want to
>>>>> revert the last 2-3 months of my work because you have an
>>>>> investment
>>>>> in an old version of the spec. With each day I spend on OCCI
>>>>> costing
>>>>> me well over €1,000 excuse me for being pissed about someon
>>>>> e with
>>>>> such a blatantly obvious conflict attacking my work and refusing
>>>>> to
>>>>> provide a coherent argument, particularly with no "camera ready"
>>>>> alternative anywhere in sight.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On 20/10/2009, at 16:51, Gary Mazz <garymazzaferro at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I've understood Sam's proposal from the beginning. I have had
>>>>>> issue
>>>>>> with from the beginning.
>>>>>>
>>>>>> Although I find it very interesting and valuable in terms of
>>>>>> economy, I have issue with it as the OCCI's primary interface
>>>>>> implementation for a few reasons which have been outlined in
>>>>>> several
>>>>>> other emails.
>>>>>>
>>>>>> It appears that Sam has created a new technology, a lower cost
>>>>>> RPC
>>>>>> mechanism, which is unproven for both small and wide scale
>>>>>> deployment. For interoperability, IMO,  occi should focus on
>>>>>> proven
>>>>>> mainstream technologies as the primary interfaces. I am not
>>>>>> suggesting, shelving or not supporting Sam's proposal, based on
>>>>>> market acceptance, it may prove to be one of many occi interface
>>>>>> implementations.
>>>>>>
>>>>>> As for cost saving in interface technologies, I do not buy into
>>>>>> the
>>>>>> idea that the occi traffic will be so overwhelming that there
>>>>>> is a
>>>>>> requirement to maximally optimize http requests and responses.
>>>>>> IMO,
>>>>>> in comparison to images and consumer data occi traffic will be
>>>>>> insignificant. I think we are worrying about spilled milk while
>>>>>> the
>>>>>> house is burning.
>>>>>>
>>>>>> There has been some discussion on supporting technologies
>>>>>> including
>>>>>> OVF. Whether occi supports OVF has not been fully discussed,
>>>>>> examined or any consensus reached. I believe adopting
>>>>>> technologies
>>>>>> like OVF will only lead to mapping issues between occi attributes
>>>>>> and the external formats creating a long term management
>>>>>> headache.
>>>>>>
>>>>>> cheers,
>>>>>> gary
>>>>>>
>>>>>>
>>>>>> Alexis Richardson wrote:
>>>>>>> OK
>>>>>>>
>>>>>>> Is Sam's statement something that we can achieve consensus
>>>>>>> around?
>>>>>>>
>>>>>>> a
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Oct 20, 2009 at 12:47 PM, Sam Johnston <samj at samj.net>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Alexis,
>>>>>>>>
>>>>>>>> Seems our posts crossed in the mail. I hope the last one clears
>>>>>>>> things up
>>>>>>>> but the fact that you're using OVF and XML/JSON interchangeably
>>>>>>>> suggests
>>>>>>>> that you [are possibly one of many who] don't grok the
>>>>>>>> proposal.
>>>>>>>> Worse, it
>>>>>>>> seems you've got it back to front in thinking of the "core" as
>>>>>>>> metadata,
>>>>>>>> which is not at all what I had intended.
>>>>>>>>
>>>>>>>> The focus is on the resources and their various
>>>>>>>> representations.
>>>>>>>> The
>>>>>>>> metadata (that is, data about data) essentially provides
>>>>>>>> whatever is
>>>>>>>> necessary to "glue" these resources together. It is basically
>>>>>>>> using HTTP as
>>>>>>>> the meta-model rather than an envelope format like Atom/SOAP
>>>>>>>> or,
>>>>>>>> worse, a
>>>>>>>> meta-model that we have to create ourselves from scratch.
>>>>>>>>
>>>>>>>> So it's more like:
>>>>>>>>
>>>>>>>> 1) OCCI is compatible with ALL existing formats, eg OVF
>>>>>>>>
>>>>>>>> 2) Existing formats are used are used for ALL representations
>>>>>>>>
>>>>>>>> 3) ALL additional metadata should be in the headers
>>>>>>>>
>>>>>>>> 4) ALL of the core stuff should be in the body (that is, the
>>>>>>>> metadata in the
>>>>>>>> headers is just there to support the data and wire it up in
>>>>>>>> useful
>>>>>>>> ways)
>>>>>>>>
>>>>>>>> I think the confusion stems from your assuming that there is
>>>>>>>> still
>>>>>>>> XML/JSON/Atom/etc. representations. There aren't. HTTP headers
>>>>>>>> provide a
>>>>>>>> single, performant, interoperable metadata channel that has
>>>>>>>> already been
>>>>>>>> both standardised and extensively implemented.
>>>>>>>>
>>>>>>>> If you've followed me this far then you should have realised
>>>>>>>> that
>>>>>>>> every HTTP
>>>>>>>> user agent (e.g. Perl's LWP, Python's urllib2, C's libcurl,
>>>>>>>> etc.)
>>>>>>>> is already
>>>>>>>> a basic OCCI client out-of-the-box. The result is that 5-line
>>>>>>>> scripts like
>>>>>>>> demo.py are functional with no dependence on client libraries
>>>>>>>> (that would
>>>>>>>> absolutely be necessary if you were to start trying to define
>>>>>>>> your
>>>>>>>> own
>>>>>>>> formats).
>>>>>>>>
>>>>>>>> Sam
>>>>>>>>
>>>>>>>> PS I'm sorry my "bunk" comment came across as referring to you
>>>>>>>> personally -
>>>>>>>> it was directed at the argument.
>>>>>>>>
>>>>>>>> On Tue, Oct 20, 2009 at 12:44 PM, Alexis Richardson
>>>>>>>> <alexis.richardson at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> I think what Sam is proposing is the following:
>>>>>>>>>
>>>>>>>>> 1) If OCCI can handle 'any' data representation, eg OVF, XML,
>>>>>>>>> JSON,
>>>>>>>>> then it needs some core / common model.  Otherwise: there can
>>>>>>>>> be no
>>>>>>>>> defined behaviour / interop
>>>>>>>>>
>>>>>>>>> 2) This core / common model is ALL metadata
>>>>>>>>>
>>>>>>>>> 3) ALL this metadata should be in the headers
>>>>>>>>>
>>>>>>>>> 4) ALL the non core stuff eg OVF payload, XML representation,
>>>>>>>>> should be in
>>>>>>>>> body
>>>>>>>>>
>>>>>>>>> Sam - is that right?
>>>>>>>>>
>>>>>>>>> a
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Oct 20, 2009 at 11:39 AM, Sam Johnston <samj at samj.net>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Tue, Oct 20, 2009 at 12:28 PM, Edmonds, AndrewX
>>>>>>>>>> <andrewx.edmonds at intel.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>> Here, from the core spec (using OVF as an example, but
>>>>>>>>>> could be
>>>>>>>>>> anything).
>>>>>>>>>> Request is green, response metadata is yellow & response
>>>>>>>>>> data/
>>>>>>>>>> payload is
>>>>>>>>>> orange:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> GET /us-east/webapp/vm01 HTTP/1.1
>>>>>>>>>>> User-Agent: occi-client/1.0 (linux) libcurl/7.19.4 OCCI/1.0
>>>>>>>>>>>        Host: cloud.example.com
>>>>>>>>>>> Accept: */*
>>>>>>>>>>>
>>>>>>>>>> < HTTP/1.1 200 OK
>>>>>>>>>> < Date: Sat, 10 Oct 2009 12:56:51 GMT
>>>>>>>>>>
>>>>>>>>>> < Content-Type: application/ovf
>>>>>>>>>> < Link: </us-east/webapp/vm01;start>;
>>>>>>>>>>
>>>>>>>>>> <       rel="http://purl.org/occi/action/start";
>>>>>>>>>> <       title="Start"
>>>>>>>>>>
>>>>>>>>>> < Link: </us-east/webapp/build.pdf>;
>>>>>>>>>> <       rel="related";
>>>>>>>>>>
>>>>>>>>>> <       title="Documentation";
>>>>>>>>>> <       type="application/pdf"
>>>>>>>>>>
>>>>>>>>>> < Category: compute;
>>>>>>>>>> <       label="Compute Resource";
>>>>>>>>>>
>>>>>>>>>> <       scheme="http://purl.org/occi/kind/"
>>>>>>>>>> < Server: occi-server/1.0 (linux) OCCI/1.0
>>>>>>>>>>
>>>>>>>>>> < Connection: close
>>>>>>>>>> <
>>>>>>>>>> < <?xml version="1.0" encoding="UTF-8"?>
>>>>>>>>>>
>>>>>>>>>> < <Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-
>>>>>>>>>> instance"
>>>>>>>>>> <           xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/
>>>>>>>>>> 1"
>>>>>>>>>>
>>>>>>>>>> <           xmlns="http://schemas.dmtf.org/ovf/envelope/1"
>>>>>>>>>> <           xml:lang="en-US">
>>>>>>>>>>
>>>>>>>>>> ...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> occi-wg mailing list
>>>>>>>>>>> occi-wg at 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.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>

More information about the occi-wg mailing list