An upfront disclaimer, I work for Google. I am not involved in Wave in any way and all of the things I discuss below are based on external documentation.
Before getting into the specifics of the issues I found, I want to point out that I'm very excited by Wave, I believe it has tremendous potential. The team has also done a good job re-using existing technologies, and providing different protocols and APIs for the various ways you can interact with a wave server.
There are actually 3 protocols and 2 APIs that are used in Wave:
- Federation (XMPP)
- The robot protocol (JSONRPC)
- The gadget API (OpenSocial)
- The client-server protocol (As defined by GWT)
The last one in that list is really nothing that needs to be, or will probably ever be documented, it is generated by GWT and when you build your own Wave client you will need to define how it talks to your Wave server. The rest of the protocols and APIs are based on existing technologies.
The robot protocol looks very easy to use, here is the code for an admittedly simple robot. Now some people have commented that Wave reminds them of Lotus Notes, and I'm sure with a little thought you could extend that to Exchange and Groove. The difference is that the extension model with Wave is events over HTTP, which makes it language agnostic, a feature you get when you define things in terms of protocols. That is, as long as you can stand up an HTTP server and parse JSON, you can create robots for Wave, which is a huge leap forward compared to the extension models for Notes, Exchange and Groove, which are all "object" based extension models. In the "object" based extension model the application exposes "objects" that are bound to locally that you manipulate to control the application, which means that your language choices are limited to those that have bindings into that object model.
All of this is very new, Wave is just starting a developer preview, and the documentation of the protocols and APIs is thin or non-existent in areas. In my observations below I've concentrated on the areas that do have documentation.
Well known location
The robot protocol uses a "well known location" for the Robot Capabilities files.
I've just about given up on
protocols that introduce new "well-known locations" in
URI space. The problem is that all the other alternatives
are problematic either on the server or the client side.
If you are going to introduce a new location, at least
follow the lead of the WebFinger Protocol
and put it below the
If you are going to introduce a "well-known location" then
make good use of it and boot-strap the rest of the URIs
for the protocol from there. In the case of Wave, put the URI of
the robot jsonrpc URI in the
capabilities.xml, don't make it
its own "well-known location". Ditto for the profiles URI.
XML and JSON
There's a mix of formats here, XML for the configuration and profiles, but the actual protocol is JSON. Why not simplify and make it JSON all the way down?
NG and Schema
In the same vein, the federation protocol schema is specified in RelaxNG while the extension manifest is defined via XML Schema.
The above points are relatively minor and I'm sure I'll have more feedback as more documentation rolls out, but I'm very excited by the technology and the direction the team is taking with Wave.