My 2¢ on Google Wave: WWW is a Unidirectional Web of Published Documents — Wave is a bidirectional Web of Instant Messages
by Nick Gall | June 1, 2009 | Comments Off on My 2¢ on Google Wave: WWW is a Unidirectional Web of Published Documents — Wave is a bidirectional Web of Instant Messages
I viewed the Google Wave demo over the past several days:
I’m already convinced that Wave represents a Web paradigm shift on par with Ajax/Web 2.0. Just as Google Maps was the killer app that opened the Ajax floodgates (even though the component technologies/standards were already in place) Wave will be the killer app that opens the HTML5/XMPP floodgates. The Wave protocol is arguably the first advance worthy of the title Web 3.0 (though I’m not encouraging anyone to use the term).
My only MAJOR concern is the Wave protocol’s impact on the core standards of the Web. Clearly, Wave embraces HTML5. What is not clear is how Wave uses URLs and HTTP? A key question for me is "Can I create a bookmark to a wave or a wavelet?" I’m less concerned with HTTP, though maximizing "backward" compatibility between HTTP actions and XMPP actions would be good evolutionary design. The reason I’m less concerned about HTTP is that URLs are the foundation of the "shared information space" that is the Web. SMTP coexists with HTTP and both use HTML and URLs in the content they transfer. Even Roy Fielding is eager to replace HTTP, e.g., with Waka. It raises the interesting question of whether the Wave protocol is roughly what Roy was proposing with Waka.
Here are a couple of my major take aways:
- The Wave client is a major proof of concept (or pilot project) for HTML5. If the wave client becomes a killer app, it will have a major (negative) impact on other RIA architectures.
- The Wave protocol is a major proof of concept for the extended use of XMPP. It transforms it from a IM/Presence protocol to a general purpose bidirectional streaming protocol.
- Whether or not the Wave client succeeds, Wave is undoubtedly going to have a major impact on how application designers approach web applications. The analogy would be that even if Google Maps had "failed" to become the dominant map site/service, it still had major impact on web app design.
Last but not least — an observation from left field:
Wave is far closer in approach and capability to Ted Nelson’s Xanadu vision than it is to Tim Berners-Lee WWW vision. Both had visions of a READ/WRITE web of linked information. One of the major design decisions TBL made was to drop the then-canonical-requirement of bidirectional links because of the scalability/complexity issue of the required "link servers" (or "link intermediaries"). Wave is fundamentally based on Wave servers. The Google tech talk on the design of the wave protocol explicitly mentions that Google rejected the approach of enabling P2P Wave interactions.
One major accidental design "decision" was when the NCSA Mosaic team decided to only implement rendering in their browser — not editing. TBL and many others have observed that the last decade or so has been a series of attempts to return to the original vision of a read/write web, eg wikis, blogs, micro-blogging. Wave seems to me to be one of the best approaches ever put forward to redesigning the WWW to be read/write (real time read/write in fact).
Read Complimentary Relevant Research
100 Data and Analytics Predictions Through 2021
Over the next few years, data and analytics programs will become even more mission-critical throughout the business and across industries....
View Relevant Webinars
Digital Business Architecture: From Strategy to Guiding Execution
New techniques have emerged to help CIOs and EA practitioners leverage business architecture to guide investment and execution decisions,...
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.