It’s just data

Google Wave

At one level, Google Wave is clearly a bold statement that “this is the type of application that every browser should be able to run natively without needing to resort to a plugin”.  At to give Google credit, they have been working relentlessly towards that vision, addressing everything from garbage collection issues, to enabling drag and drop of photos, to providing compelling content (e.g., Google Maps, GMail, and now Google Wave).

At a lower level, Google Wave is a severely constrained set of elements and styles, coupled with a powerful, and largely undocumented at this point, set of annotations. Note that the base grammar has no notion of links, that’s something that is layered on in terms of annotations.  Looking at the source to the Tweety Servlet, one can deduce that the following is the way to establish a link:

textView.setAnnotation(range, "link/manual", uri);

I say “deduce” as I have yet to find this in the documentation any place.

An annotation is associated with a range of items.  Wave operations treat every 16-bit Unicode unit and tag as an “item”, meaning that developers will have to deal with NFC vs NFD issues as well as Astral Plane characters.  The sixteen bit illusion is still going strong.

Waves themselves are identified with a non-URI of the form!w+waveID.

In a move that is sure to frustrate page design tools, embedding is done purely via JavaScript.  Want to know basic information such as a list of what waves are included on a page?  Simple.  Simply load the page, run all the referenced JavaScript,an intercept all calls that involve WavePanels.  But this is pre-beta at this point, hopefully a more declarative mechanism will be added over time.

UIs can be extended and customized by providing wave-aware gadgets.

But stepping back a bit, the entire and much hyped HTML5 interface is just a facade.  That’s not a criticism, in fact that’s generally the way the web works.  What makes Google Wave particularly interesting is that there is an API which operates directly on the repository.  Furthermore, you can host your own server, and such servers federate using XMPP.

These servers are not merely passive, they can actively interact with processes called “robots” using HTTP (More specifically, JSON-RPC over POST).  Once invoked, these robots have access to a full range of operations (Java, Python).  The Python library implementation looks relatively straightforward, and would be relatively easy to port to, say Ruby.

Working on such a Ruby library, a Rails generator for Robots, and ultimately a Ruby implementation of the XMPP server itself would be of interest to me, once the project is open to outside participants

Just simply working on the Ruby Library and Rails generator alone would enable one to build a “four tier” application where a wave is a front-end to an existing Rails application.