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

[Sam Johnston]

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<http://tools.ietf.org/html/draft-nottingham-http-link-header>
.

Would it make you feel more comfortable if I were to tell you that Amazon
have been using HTTP headers for arbitrary
metadata<http://docs.amazonwebservices.com/AmazonS3/latest/index.html?UsingMetadata.html>for
years? "In REST, user metadata keys must begin with "x-amz-meta-" to
distinguish them as custom HTTP headers."

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

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

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20091020/1336a597/attachment.html