Google Wave hackathon

来月の Google I/O では Google Wave に関する新しい発表がある！かどうかは分かりませんが、リアルタイム性の高いメッセージングには興味がありましたので、Google Wave hackathon に参加してきました。4月も半ばだというのに積雪が散見される天候なので、渋谷のセルリアンタワーにある Google のオフィスに集まった参加者はまばらでした。

ハッカソンでは何をやっても良いのですが、とりあえず、どんなプロトコルになっていて、どんなデータがやりとりされているのかを調べてみることにしました。周りの人のほとんどは2月に発表された robot v2 の API に関することをやっていましたが、まぁそれはそれで。どうやって動かすか、何を動かすか、という違いでしょうか。

まずは自己紹介と今回のメインである robot v2 に関する紹介がありました。v2 からはロボットが active な処理を実行できるようになったそうです。v1 では wavelet へのアクションに対してロボットが反応する、というモデルでしたが、それに加えて外部状態の変化を wavelet に反映させることができます。twitter のようなマイクロブログの内容や IRC のログを wavelet に取り込むことができるみたいです。active な処理ができるようになると危険なのがデータ量の肥大化ですが、event を filter にかけるとロボットに送られるデータを制限できますので、Google App Engine の quota 制限にひっかかりにくくなるそうです。DocumentChanged イベントへの filter 定義は必須だと思った方がよいとのことです。Python の API ドキュメントにも通信量の増加に注意してね、と記載されています。

This event is fired after any changes in the document and should be used carefully to keep the amount of traffic to the robot reasonable. Use filters where appropriate.

さて、プロトコルのお話です。正式名称は Google Wave Federation Protocol といい、"Federation" というのがポイントです。現在の状況では、wavesandbox.com は federating ですが、wave.google.com は federating ではないようです。federate の嬉しい点は、複数のサーバーに処理を分散できることです。Google のように超巨大なデータセンターを持っている場合や、使う人が少ないしサーバーがダウンしても問題ない運用の場合は federate の利点は享受できないかもしれませんが、イントラネットのようなローカルなネットワーク内で運用する場合には、federate を利用できるとスケールアウトを実現でき、単一障害点を取り除くことができます。まだ仕様がきっちりと固まっているわけではありませんが、それなりの実装がでてくるのが楽しみです。詳しい仕様に関してはホワイトペーパーに記載されています。なお、server-server のプロトコル (federation) を先に決めたい、という方向性で、client-server のプロトコルは後回しのようです。

ともあれ実際に動かしてみないと海のものとも山のものとも知れませんので、サーバを動かしてみることにしました。クライアントの実装がちょっと追いついていない感じは否めませんが、動くものがあるのは良いことです。手順はプロジェクトの wiki に記載されている通りに進めれば大丈夫そうです。手元の環境では XMPP サーバーとして openfire 3.6.4 をインストールしました。Windows のインストーラがありますので、非常に簡単に設定できました。
自分が試した範囲での注意点は次の二点でした。

• Windows だとコマンドプロンプトが ANSI カラーに対応してないからパッチを当てて装飾をやめる。再コンパイルするときは必要なターゲットだけを指定 (ant compile dist-client-console) する。
• MacOSX のデフォルトは Java5 なので、Java6 にバージョンアップする。バージョンの切り替えがちょっとメンドイ。ant でビルドすると test でコケルのはそのままにしておく。

Windows の件に関しては、Java の Swing 版を作ったよ、という人もいました。Ubuntu でのスクリーンショットのように色づけされませんが、実用上は問題ないと思います。なお、この件は FAQ に記載されていました。FAQ にはその他にも有用な情報がありましたので、初めに一回は目を通すべきだと思います。

データの仕様は XML で定義されていますが、文書の差分情報 (<delta />) の表現には Google の Protocol Buffer を使います。差分には新規追加と更新があり、更新の場合は差分の計算が発生します。"hoge" を "hello wave" で上書きする場合は、先頭の "h" だけが共通であるため、"oge" を削除 (delete_characters: "oge") して "ello wave" を追加 (characters: "ello wave") します。この辺りの操作は複数のユーザーが関係してくると非常に複雑になりそうですので、深入りしませんでした。詳しくは OT (Operational Transformation) の仕様を理解する必要がありそうです。OT は "the theoretical framework of concurrency control." であり、Wave での目標も記述されています。

Wave stands as a solution that offers both live concurrent editing and rich text document support.

概念は理解できそうですが、実装に落とし込むのは難しそうです。

Protocol Buffer に関しては、Google Wave Federation Protocol 仕様書の Appendix B. Protocol Buffers の内容をコピーして wave.proto というファイルに保存し、次のコマンドを実行することで Python でのインターフェイスファイルを生成できます。"protoc" は Protocol Buffer の Windows バイナリのことで、プロジェクトのサイトからダウンロードできます。

$ mkdir wave-console
$ protoc wave.proto --python_out=wave-console
$ ls wave-console
wave_pb2.py

生成された wave_pb2.py は普通の Python のソースコードで、先頭の方を読んでみると google.protobuf モジュールが必要であることがわかります。この辺の設定に関してはまたの機会に挑戦してみたいと思います。

from google.protobuf import descriptor
from google.protobuf import message
from google.protobuf import reflection
from google.protobuf import descriptor_pb2

差分情報を Protocol Buffer で処理して BASE64 エンコードすることで、実際のデータを生成するための一部を生成できます。仕様に即したデータを作るまでの道のりは険しそうです。もう一段階上のレイヤーのライブラリが登場すると、サーバーを開発する敷居が下がるのではないでしょうか。

Wave はメールを置き換えるような新しい概念、新しい技術のため、普及までには時間がかかる (もしくは普及しない) かもしれませんが、データ構造、プロトコルはよく考えられているなぁと思いました。今回のハッカソンを企画・運営してくれた方、会場を提供してくださった Google には感謝です。

めも

• Closure だとリスト処理、ループ処理をシンプルに書ける。
• 合作で動画とか画像を編集できると楽しい。
• 裏でグーグル内のロボットが動いているかも。無限ループに陥ったら Application を disable する。App Engine の管理コンソールでできる。