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

[eprparadocs at gmail.com]

Pablum for the masses!

Chance


Sam Johnston wrote:
> FYI, some pertinent discussion about HTTP from another list.
> 
> ---------- Forwarded message ----------
> From: *Sam Johnston* <samj at samj.net <mailto: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 <mailto:cloudforum at googlegroups.com>
> 
> 
> On Wed, Jun 3, 2009 at 3:04 PM, Gregg Wonderly <greggwon at gmail.com
> <mailto: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
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg