mnot’s blog

Design depends largely on constraints.” — Charles Eames

Friday, 29 May 2009

Most Revealing Google Wave Comment

Filed under: Caching HTTP Web

Everybody’s atwitter (yeah, sue me) about the Google Wave developer preview. Lots of new stuff there, but for me the most revealing comment, almost a throwaway, was here:

</embed>

Did we mention we use Squid?

In other words, Google’s hot new, Web 2.0-on-steroids HTML5 XMPP++ open social platform buzzword generator works well with, indeed relies upon (for the purposes of making a nice demo) a more than 15-year-old piece of nearly-forgotten (in some quarters) Web infrastructure.

That’s pretty cool.


7 Comments

Fredrik said:

I’m pretty sure he says “gwit”, which is how Google Web Toolkit (GWT) is usually pronounced by Googlers.

Saturday, May 30 2009 at 1:21 AM

Roy T. Fielding said:

I watched the video before reading your blog and I am sure he meant GWT. The protocol is XMPP with TLS transport encryption containing client-signed operations, which makes perfect sense when the payload primarily consists of XML tree ops on a shared state. I think the architecture is very well thought out, at least on the scale of a few hundred simultaneous users per server, and it will be interesting to see how well federation works at expanding that to Internet scale. I expect the load to spread evenly, so that bodes well for cloud-based scalability. One big advantage is that they can use the same active connections as Google Talk.

Saturday, May 30 2009 at 6:29 AM

Fredrik said:

“Huh. Still a pretty revealing comment, I’d say ;)”

Lars uses a short break later on to thank the GWT team, so I’m not sure the use of GWT for the client-side implementation is that much of a secret.

“they could have extended the HTTP caching model instead”

Are you talking about Wave or HTML5 in general? For Wave, I’m pretty sure that Gears is only used to get image drag and drop in all browsers, and to generate preview images before uploading the full images. But I’m not working on the product, so I might be wrong.

Sunday, May 31 2009 at 12:02 PM

Roy T. Fielding said:

A quick read suggests that they are using SRV records to indicate which address:port should receive the TCP connect, followed by immediate TLS and then XMPP over the encrypted channel. I suspect they aren’t worried about firewall traversal or name-based virtual hosts because federation is at the domain level.

In other words, this is a lot more like Lotus Notes than anything else. The big difference is that the protocols are open and Google actually has the machines to support this type of scalability. I am guessing that they will use the existing Google Talk network for clients of their own gmail domain.

BTW, my earlier comment had one thing wrong – the operations are being signed at the domain level using the domain’s certificates, not by client-certs. I have no idea how that is going to work when a domain cert expires. I’d love to see a network trace of the character-level interaction over XMPP to see how it compares to “other” protocols in terms of overhead.

Monday, June 1 2009 at 7:23 AM

Fredrik said:

XMPP is used on the federation level; communication between the browser client used in the demo and the server it’s talking to is done via good old AJAXy HTTP(S).

(If I understand things correctly, that is).

But it’s the federation side of things that’s really interesting from an engineering perspective. That, and the algorithms used for operational transformations. And the extension mechanisms, including the novel approach used for the spelling checker. And how this whole thing pushes the limits for what you can do in a web browser. And a lot of other things. I’ve known about this project for some time, and read most internal papers, but I still haven’t fully grokked even a fraction of it…

Monday, June 1 2009 at 10:07 AM

Creative Commons