Google Wave's Web of Protocols (diagram and commentary) | Hacker News Reader

Google Wave's Web of Protocols (diagram and commentary)

cubiclemuses.com

42 pointsjaaron13 comments

As this blog post points out, unless the browser-server component gets opened up, and it doesn't look to me like it's going to, Wave is a big vendor lock-in project, with the Google interface the only one used by humans, and all the federations stuff designed only for "bots". "We're open" becomes just misdirection and fake hype.

But I think that's the least of Wave's problems at the moment. If they get the server bugs worked out, and figure out access control, then we can start talking about interoperability.

I've been watching this situation closely, and I too am concerned about how a client/server protocol specification isn't being prioritized higher.

That said, does the Google Talk client in the sidebar of my GMail client speak XMPP? Of course not...it's a web app, and it needs to talk to a web server as an intermediary to a jabber server somewhere. I can log in using a desktop GUI jabber client to an actual XMPP listener if I want to, and that is what is important. I don't care one whit about the protocol that GMail Chat uses to talk to its back end. That's a private matter between Google and Google.

It's not the browser-server protocol that needs to be specified, but rather some other client-server protocol, without any assumption that the client is a browser.

It seems to me that the relationship between "the web" and Wave is entirely incidental, stemming from the fact that their reference client runs in a browser. One might well write a client in Cocoa or GTK, in which case an open specification for how Google's Wave client, written in GWT, communicates with its back end does us no good at all.

However, I'm willing to give it time. It feels like they've got bigger fish to fry at the moment, based on this thread:

http://groups.google.com/group/wave-protocol/browse_thread/t...

Thanks, that's a great link... Best message in the thread is from Anthony Baxter @Google, about halfway down the page:

"When I and other googlers have said 'there's no concrete client-server protocol', you can attach an unspoken 'yet' to that. We don't know what it should look like in it's final form. On the other hand, we have a fair idea about the requirements and needs of the federation protocol, which is why we took at stab at writing that down first.

"If anyone has ideas about what this should look like based on what they've seen so far, start a discussion on it. It's not necessary for Google to come down the mountain with a completed standard engraved in stone. Or even in something softer, like soap."

> That said, does the Google Talk client in the sidebar of my GMail client speak XMPP? Of course not...it's a web app,[...]

It doesn't, but it should. This is something we’ve been trying to address with the Orbited and JS.IO projects (links below). Building in-browser clients on a JavaScript XMPP client saves developer effort and aids interop, because each web client isn't inventing its own ad-hoc buggy mutated version of the protocol, based essentially on the same semantics, but with arbitrary changes to syntax.

http://orbited.org/

http://js.io/

That's a nice idea. There are other ways to skin that cat: if you have a server-side library that speaks perfect jabber, your web client can invoke it from afar. The library's API should work the same either way. Heck, if it's a Java library use GWT RPC.

I was surprised to learn that there is no standardized client-server protocol, but it makes sense if they are building a browser based client.

Any sensible protocol would likely be outside of current browser capabilities and the scheme they are using (based on GWT) is unsuitable for standardization. I wouldn't expect them to spend resources developing a protocol they aren't going to use and they would likely do a bad job of it anyway, for that same reason.

The protocol should be designed by whoever makes the first local client (which BTW I would be overjoyed to do, if someone wants to keep me afloat while I do it).

They are taking federation pretty seriously. They've opened a reference implementation and some third party developers are already running their own servers. When someone writes a client, or a web interface for a server, we can use Wave completely independent of Google. I don't see how lock-in would happen in the long run.

In the worst case, it shouldn't be hard to RE their GWT marshalling and hack a new front end on to their server.

I've written about this before. Until Google releases both code and protocol for a client-server integration, Wave is too complicated for the web. I spent a whole week barely trying to emulate the same thing in Javascript and I couldn't do it.

I'm concerned about this too. The web client at the moment is brutally unresponsive and hemorrhages memory in Firefox. I know it's far from release, but I'm skeptical that these problems can ever be solved in a present day real world web app. If we had worker threads and some browser patches, maybe.

Every time I hear 'Wave' I think of 'Ripscript' - http://www.bbsdocumentary.com/library/PROGRAMS/GRAPHICS/RIPS...

I'm surprised by the lack of scepticism of Google Wave. It seems quite dodgy for the next "killer app".

Once I actually used it, even in its current buggy pre-alpha state, I realized that Wave is actually pretty cool and there are all sorts of ways in which I would prefer to use a tool like wave over a wiki, email or IM. I believe Wave has serious potential, but it's also got a long way to go.

I do like that everything runs over HTTP at its base...

The federation protocol (server to server) is over XMPP, not HTTP.

Reply on news.ycombinator.com