Fwd: HTTP is Dead, Long Live The Realtime Cloud
FYI, some pertinent discussion about HTTP from another list. ---------- Forwarded message ---------- From: Sam Johnston <samj@samj.net> Date: Wed, Jun 3, 2009 at 3:38 PM Subject: Re: HTTP is Dead, Long Live The Realtime Cloud To: cloudforum@googlegroups.com On Wed, Jun 3, 2009 at 3:04 PM, Gregg Wonderly <greggwon@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
Pablum for the masses! Chance Sam Johnston wrote:
FYI, some pertinent discussion about HTTP from another list.
---------- Forwarded message ---------- From: *Sam Johnston* <samj@samj.net <mailto:samj@samj.net>> Date: Wed, Jun 3, 2009 at 3:38 PM Subject: Re: HTTP is Dead, Long Live The Realtime Cloud To: cloudforum@googlegroups.com <mailto:cloudforum@googlegroups.com>
On Wed, Jun 3, 2009 at 3:04 PM, Gregg Wonderly <greggwon@gmail.com <mailto:greggwon@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
participants (2)
-
eprparadocs＠gmail.com -
Sam Johnston