[occi-wg] Fwd: HTTP is Dead, Long Live The Realtime Cloud

[Sam Johnston]

FYI, some pertinent discussion about HTTP from another list.

---------- Forwarded message ----------
From: Sam Johnston <samj at samj.net>
Date: Wed, Jun 3, 2009 at 3:38 PM
Subject: Re: HTTP is Dead, Long Live The Realtime Cloud
To: cloudforum at googlegroups.com


On Wed, Jun 3, 2009 at 3:04 PM, Gregg Wonderly <greggwon at gmail.com> wrote:

> HTTP is not really the power point of web delivery.  AJAX, HTML, CSS, DHTML
> etc standards are what make it powerful.  REST is a useful architectural
> model, and application protocols on top of HTTP can still extend the model
> to provide more powerful application APIs that will simplify development of
> advanced web delivered applications.


Pretty much everything (useful) is built on top of HTTP and if anything the
lesson we should learn from previous attempts to deviate from it (SOAP,
XML-RPC and WS-*) is that we should in fact be embracing it and getting as
close to it as possible.

Earlier (in the context of OCCI development) I asked Is AtomPub already the
HTTP of cloud computing?<http://samj.net/2009/05/is-atompub-already-http-of-cloud.html>,
figuring that it delivered the out-of-band "Web Linking" that HTTP couldn't
(traditional web linking is in-band, through use of HTML's "A" and "LINK"
elements, but that doesn't work for non-HTML payloads like OVF, ODF, etc.).

There was (unfortunately) huge backlash from the XML-xenophobes (I say
unfortunately because the RealCloud™ players, most notably Google and
Microsoft, have adopted it strategically for pretty much everything they're
doing in the space) so it has been dropped at least for the time being from
individual resources (even if it remains for collections, ironically
increasing complexity by requiring two different approaches depending on
cardinality).

Anyway if you ignore the problem of collections (which can be passed either
by reference as a plain text list of links, or by value with a meta-model
like Atom - with O(n+1) and O(1) performance respectively) then it turns out
HTTP actually provides for web linking in the earlier drafts, by way of the
Link: HTTP header and the LINK and UNLINK HTTP verbs. Obviously the guys
responsible for writing this stuff could see further into the future than
the guys implementing it!

The point is that using native HTTP it is possible to create an extremely
RESTful, scalable and trivial to use "Resource Oriented Architecture (ROA)"
that "just makes sense" - every resource has a URL and can be retrieved in
various representations (e.g. a DOC could also be retrieved as PDF, a song
as MP3 or AAC and a virtual machine as OVF or a PNG screenshot), operations
can be repeated without fear of repurcussions, everything can be cached,
associations can be created between resources (e.g. a compute resource
having a link to storage and network resources), etc. This is far easier to
understand and write to than an RPC-based approach often associated with
SOA.

As for Wave, there's even a "HTTP PATCH" method currently being
reincarnated<http://tools.ietf.org/html/draft-dusseault-http-patch-14>that
allows you to make specific changes to a document rather than
replacing
it altogether with a PUT.

In summary, HTTP is far more powerful than you might think and given the
enormous amount of infrastructure and optimisation built around it you would
want to have one hell of a good reason to deviate from it. For Google having
an existing XMPP infrastructure (Google Talk) is strong incentive, but that
doesn't make it the best approach for the rest of us - work being done
around browsers becoming servers is also potentially applicable.

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