Joe Gregorio
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 wave embed API (Javascript)
- 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
arguing against
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 /,wellknown/ path.
Hypertext
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.
Posted by Jared Hanson on 2009-06-01
That is, as long as you can stand up an HTTP server and parse JSON, you can create robots for Wave
Quite a leap of faith there. I heard similar things about XML and SOAP a few years ago.
Note: while it is true that the tunnel everything over HTTP POST
JSON-RPC protocol is based on JSON, Waves are XML and can be served over XMPP.
Posted by Sam Ruby on 2009-06-01
Agreed, the Java-isms need to be expunged from the wire format, and also from the Python library.
They are still a work and progress, both from a protocol and API standpoint. In my opinion (having written the bulk of the Python API), I see them as much as out-of-the-box frameworks as I do "examples" how to communicate with Wave servers.
I've seen other comments in to the same effect that the protocol is very much a work in progress.
while it is true that the "tunnel everything over HTTP POST" JSON-RPC protocol is based on JSON, Waves are XML and can be served over XMPP.
My understanding is that XMPP is for federation of servers, not for robots.
Posted by Joe Gregorio on 2009-06-01
Waves are containers for Wavelets. Wavelets are containers for Blips. Blips have content that are XML. So we have XML tunneled over JSON tunneled over HTTP POST. Whee!
And none of the above matters a bit. JSON doesn't guarantee interop, nor does XML or YAML or binary prevent such. What makes portions of the Wave API opaque is the parts where the developers gave into temptation and serialized internal state (inside-out) vs designing an API (outside-in).
P.S. Independent of what the XMPP interface is "for", I plan to look into what can be done with it. XMPP is much better than HTTP for client initiated interactions, particularly for ones behind a NAT. The way I figure it, if I can run my own server, I can create my own identities, and some of those identities can be scripted, and scripted identities can do whatever a person could do...
Posted by Sam Ruby on 2009-06-01
What makes portions of the Wave API opaque is the parts where the developers gave into temptation and serialized internal state (inside-out) vs designing an API (outside-in).
I agree completely.
Posted by Joe Gregorio on 2009-06-01
I guess I don't really understand why they don't base all three of their protocols on XMPP. Isn't this how things work in the Jabber world? I suppose you would need something like HTML5 WebSockets[1] to make this work cleanly with a browser-based client.
[1] http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-13
Posted by James Clark on 2009-06-02
Hey Joe, do you know if you have to use GWT to use parts of Wave?
It's interesting that the Wave team so fully bought into GWT. Previously I was completely skeptical of GWT because it seemed like a crutch for Java programmers who wanted to do Ajax but didn't want to learn JavaScript nor leave their Java tools and knowledge behind.
I always figured that the "evolution of JavaScript" would be higher level libraries and frameworks, rather than other programming languages compiled into JavaScript. But I guess it's the web and people can do what works for them.
Unless Wave prereqs GWT :-)
Posted by Bill Higgins on 2009-06-02
I'm personally of the opinion that this should be XMPP all the way. I get frustrated by the monkey patching of protocols into (what I see as) inappropriate usage scenarios. I would love there to be a standard API (much like DOM) for browsers to adopt that manages XMPP communications as a parallel to XHR. Leave HTTP for what it is good at, and do persistent connections another way.
I'd add a couple more 'issues' to the list (the scare quotes are because I'm not sure whether these are genuine issues or design choices that make sense given the use-cases they are targeting.) The first is relating to the design of the protocol as fundamentally client-server with authoritative servers. I believe that the future lies with mesh-oriented, failure tolerant protocols that do not require a single entity, such as a company hosting a Wave server, to have high-availability and to exist forever more. Not only is this scenario ignoring the major issues surrounding archiving (we do not want a 'lost century' scenario), but they also do not match the trends towards mobile, ad hoc and brittle connections and networks. Granted, Waves do get copied to other servers, however once a group of participants splits it cannot be reformed. The Palimpsest algorithm (which has a startlingly similar data model to Wave) has the ability to cope with deltas coming out of order, common in scenarios with poor, intermittent connections and high-latency. Given the similarities between the models, I presume that Palimpsest was considered as prior work and I am curious about what problems arise within its model that cause Wave to have different properties. I've posted to the Wave protocol group, but have had no response so far.
The second issue is related to the first and involves the model of conversations adopted. Wave appears to very strictly insist that conversations are trees. In my experience with using email, and in real life discussions, I rarely follow a tree model. Often one gets a degree of redundancy in questioning, either through repetition (which can happen even in live update scenarios) or through unwittingly overlapping concerns, where I like to respond to two or more people's points at once. I'd love to see the Wave protocol support such DAG-structured communications. I frequently find that points are most clearly explained when I can tie together ideas from two or more participants' individual issues. I am, to clarify, a synthetic thinker. The current system seems most suited to analytic thinking, but there are a lot of synthetic thinkers out there. I'd personally find it difficult or counterproductive to express myself analytically.
Overall, however, I wouldn't want people to think I'm against Wave. I'm quite excited by some of the potential, but I'd love to know that these issues are addressed (either by changing the protocol or model to support them or by saying 'out of scope' or similarly satisfying me that they've been considered albeit maybe briefly.) I'm looking forward to seeing what I and others can make out of this idea.
Posted by Joe Geldart on 2009-06-02
I'm personally of the opinion that this should be XMPP all the way.
That's an interesting idea, one that isn't really viable until Web Sockets are ubiquitous. Even then I would disagree in the case of the Robot protocol.
I believe that the future lies with mesh-oriented, failure tolerant protocols...
What you want is Groove.
Posted by Joe Gregorio on 2009-06-02
Thanks, let's make sure both groups stay in sync. We don't need three or four "well-known locations".
Posted by Joe Gregorio on 2009-06-02
I was a bit surprised by your comment that you don't see any need for the client-server protocol to be documented. Surely it would be desirable for any Wave client to work with any Wave server, just as you want any browser to work with any HTTP server or any Jabber client to work with any Jabber server.
I think about this in a manner similar to GMail and SMTP: the underlying protocol that has an RFC is SMTP, you can send and receive email using a myriad of clients and none of them are the worse for wear not knowing what the protocol is that GMail uses to talk between the browser and the server.
I guess I don't really understand why they don't base all three of their protocols on XMPP.
You answer part of the question yourself about browser capabilities. I am actually impressed that they defined a separate robot protocol that isn't XMPP. I know the temptation is definitely "when you have a hammer ..." Having a protocol that is much simpler, on the level of WebHooks, is at this point a big deal given current deployment of XMPP. I've been wondering if the robot protocol could see wider deployment beyond Wave. Could I format comments to this blog as blips and then send them through robots when they're submitted, as a way to add features?
Posted by Joe Gregorio on 2009-06-02
Hey Joe, do you know if you have to use GWT to use parts of Wave?
No, it is not required at all.
As for GWT, we've talked enough that you should know my opinion :)
Posted by Joe Gregorio on 2009-06-02
That's an interesting idea, one that isn't really viable until Web Sockets are ubiquitous. Even then I would disagree in the case of the Robot protocol.
I understand it isn't possible now, however I've always been a fan of deciding where I want to be in the far future and then working through all the intermediate steps as they become necessary.
What you want is Groove.
Possibly, but I would prefer the open protocol being touted as 'email invented now' to support such properties. I think they're good and desirable properties given what we've learnt about the problems with the Internet-as-is in such situations, and the surprising number of applications which fall into this area. I attended a talk by Vint Cerf in London in September which spent a fair amount of time talking about just this. Just think of the frustration you have when your Blackberry or iPhone or Android phone is out of signal. Wouldn't it be nice to still be able to collaborate with people who are within line of sight using these tools based on an open system?
Posted by Joe Geldart on 2009-06-03
Posted by Patrick Mueller on 2009-06-03
Posted by Robert Cooper on 2009-06-01