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

[Alexis Richardson]

On Mon, Oct 19, 2009 at 11:33 PM, Sam Johnston <samj at samj.net> wrote:
> On Tue, Oct 20, 2009 at 12:07 AM, Alexis Richardson
> <alexis.richardson at gmail.com> wrote:
>>
>> If applying this to more metadata has been such a good idea for a
>> decade, why wasn't it adopted much more?  Answer - we don't know.
>> This absence of certainty appears to have been a legitimate source of
>> concern for many people.
>
> Likely because the information on the web was until now useful for humans
> but opaque to computers. As we're taking it to the next level with cloud,
> semweb, etc. our demands on the aging infrastructure are increasing and
> features such as the Link: header which were originally specified in HTTP
> back in 1997 are being revitalised.

By all means revitalise - but through a separate RFC showing the
general pattern - then suggest applying it to OCCI and other specs.


> Would it make you feel more comfortable if I were to tell you that Amazon
> have been using HTTP headers for arbitrary metadata for years? "In REST,
> user metadata keys must begin with "x-amz-meta-" to distinguish them as
> custom HTTP headers."

No it would not.  Using some of this for S3 does not prove that it
works for managing running images.



>> We are doing infrastructure, and basing it as much as possible on prior
>> art.
>
> We are doing infrastructure today but my proposed roadmap has provision for
> both platform and application layers tomorrow (which is why I went to great
> lengths to separate out OCCI Core after the fact). Sure we should take one
> step at a time but confining ourselves to infrastructure is not seeing the
> forest for the trees. Furthermore, the standard as it stands today can
> trivially cater for any kind of resource you throw at it because the data
> channel completely clean (there are no Atom or SOAP headers, XML, JSON or
> other formats that need parsing - everything you need is right there in your
> existing HTTP user agent).

This does not matter if we don't have consensus.




> It's taken me 6 months pretty much full time to crack this particular nut
> and I'd very much appreciate if you were to give this work the consideration
> it deserves.

The consideration that it deserves is: LOTS. That is the problem.


> As for "prior art", were that the case we'd have just rubber
> stamped one of many existing infrastructure APIs (and in doing so delivered
> one vendor a huge competitive advantage over all the others).

This is a non sequitur.

alexis