No Comment

Google Wave was in the news the last week, Sept. 30th was the date that platform was opened to the wider developer community. The actual big news event was last May when they presented a demo at their developers conference. The video of that demo is an hour and 20 minutes long, but quite illuminating. I sat down over the weekend and watched it, expecting it to be a slog, but it was quite entertaining.

While watching it, I took some notes, and what follows is a digested version of my immediate responses to the demo.

First off is that all of these web services have on main flaw, a single point of failure, i.e., network connectivity (either yours or Google’s). If, for instance, you use Google hosted services for your Wave conversations, if your Internet is down, you’re dead in the water. Of course, if your Internet is down, you also can’t receive email, so perhaps that’s not so big a deal, but the advantages of Wave come in the real-time and near-real-time collaboration, whereas email suffers very little from the latency problem that a local internet connection failure imposes.

Google certainly has big pipes to and from their servers and lots of redundancy, but they occastionally do have failures in some of their apps that cause them to be unreachable or slow. But consider if you decide to run your own Wave server — likely you would do so on a commercial hosting service rather than on your local office’s servers, but either way, you’re again in the situation where a crucial app is network-based, and only as reliable as the networks you depend on.

Embedding the Wave in a Blog:
Is just anyone allowed to participate in a WAVE embedded in the blog, or do you have to have user authentication in place?

SPELLCHECK DEMO
Brilliant application of their Google search spelling algorithms, but how often does it actually fuck up?

IM MODEL
The default is edits are immediately visible, indeed, they haven’t even built the feature to hide immediate updates. If you have a 10% rate of comments that you don’t want others to see, how many times will you end up accidentally sharing something you don’t want others to see until you’ve finished it? It seems to me, this makes it necessary to be very aware of the nature of the communication before you initiate it, and with certain people you’d want the default to be HIDE updates until SEND, while with others, you’d you’d want it to default to immediate.

A complicated problem, and one that will, I think, cause endless problems for end users — how many people pay for the email services that allow you to undo SEND in an email?

EXTENSIONS vs. ROBOTS
The presentation has confused me. I thought I understood the difference, but now I’m confused. They mentioned a distinction that a robot was server-side and an extension client-side, but the demo of Polly the Pollster seemed to obscure this — I feel less distinction now than I did before going into the example. Perhaps this because they’ve successfully abstracted the underlying technology so that to the user the difference is undetectable.

MORE CONFUSION
At the conclusion of the robot demo, Lars says “OK, that’s EXTENSIONS for you” (1:04), which just goes to show that I’m not the only one who is confused.

The difference is clearly server-side vs. client-side:

1. an extension runs in the client. Updates to it get passed to the server as part of the wave and distributed through the normal wave distribution process.
2. a robot is code running on the server that waits to see something pass by it in the wave that triggers its server-side behavior, whatever that may happen to be.
3. robots have client-side UI elements that dump relevent XML into the wave that will then trigger the server-side action from the robot.
4. thus, robots are client-side extensions that modify the wave plus a server-side process that reacts to those changes to the wave stream.

So, robots and extensions are *not* two different things. A robot is just an extension paired with server-side actions/

SECURITY/CONTENT CONTROL
While it might seem tempting to integrate a Wave into a website, the problem is the same with the Wave as with SideWiki — you don’t have control. It’s collaborative, so you have all the problems that come with collaboration, where everyone is equal and nobody gets veto power. That is, unless they’ve actually engineered it for superusers who have the privilege of editing the way, i.e., removing from the playback those things that they don’t want part of the permanent record.

IMPORTANCE OF DEVELOPERS
Interesting that the conclusion of the talk is Google’s realization of the importance of developers in making a platform successful. This is something MS always understood, something that Apple has only imperfectly understood, and something that this video shows Google is obviously coming to understand.