Google Wave and consistency 一貫性
Yasushi Shinjo
先日、Google Wave というのが、発表さました。
http://wave.google.com/
http://www.atmarkit.co.jp/news/200905/29/wave.html
感じとしては、Google は、
・複数人で 1 つの XML 文書を Wiki みたいにエディットしましょう
・そのためのプロトコルなどを決めました
・みんなでこれでプログラムを作ってね
といいたいんでしょうか。センスはそんなには悪くないと思いまし
た。Google がやっていると言うところが、昔の Microsoft っぽい
感じがして、ちょっとね。Google は、これでどうやって儲るつも
りなんでしょうかね。
ポーリング避けるために、Comet 使うという話もありますが、XMPP
でも良いみたい。
みんなで更新すると、一貫性の問題が出てくるはずだれど、どうやっ
ているんでしょうね。chat なら追加だけしかないから簡単かもし
れないけれど。
中継するサーバは勝手に上げてやれということなんですかね。自前
で提供するというよりは。
「bot」という言葉の使い方が、イマイチな気もしました。botnet
の bot という連想から。agent も、昔の流行語って感じだけど。
＼＼ 新城 靖 （しんじょう やすし） ＼＼
＼＼ 筑波大学 電子・情報 ＼＼
Yasushi Shinjo
In article <YAS.09Ma...@kirk.is.tsukuba.ac.jp>
y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes:
> みんなで更新すると、一貫性の問題が出てくるはずだれど、どうやっ
> ているんでしょうね。chat なら追加だけしかないから簡単かもし
> れないけれど。
と書きましたが、こんな記事も見つかりました。
http://techon.nikkeibp.co.jp/article/NEWS/20090529/170981/
【Google I/O】Google Waveのキモは同時並行制御
2009/05/29 15:52
北郷 達郎
この記事だけでは良く分からないけれど、Xerox PARC の Jupiter
Collaboration System の技術が使われているみたい。まだ良く分
かってないけれど、たとえ中央のサーバあっても、末端のクライア
ントから見た時には矛盾することはありそうなんだけどなあ。たと
えば、誰かある行を修正していて、だれかがその行を削除したりす
ると、どうなるんだろう。
tesi...@diary.ocn.ne.jp
> 新城＠筑波大学情報です。
>
> この記事だけでは良く分からないけれど、Xerox PARC の Jupiter
> Collaboration System の技術が使われているみたい。まだ良く分
> かってないけれど、たとえ中央のサーバあっても、末端のクライア
> ントから見た時には矛盾することはありそうなんだけどなあ。たと
> えば、誰かある行を修正していて、だれかがその行を削除したりす
> ると、どうなるんだろう。
こんな記事がありました：
http://www.atmarkit.co.jp/news/200906/01/wave.html
「開発チームが明かす、Google Waveの実装概要」
理解していませんが、目についたところを拾ってみると、
・メールシステムを作り直すとしたらどうやるかという問題意識でスタートした
・矛盾が起こらないようにするため、Waveでは各操作を変換する
「オペレーション変換」を実装している
・任意の2つの操作を1つの操作に合成する合成関数を実装した。
任意の2本の操作ストリームをこの合成器に流し込むと、
合成後の1本の操作ストリームが出てくる。
これにより、オペレーション変換を軽くすることができる。
・操作の合成に関して、編集履歴の蓄積から任意のバージョンを引き出すときに
最小限の計算量で済ませるために、「Composition tree」と呼ぶデータ構造
(2分木?) を採用した。
・クライアントから操作（差分）を送るときに
サーバから明示的に送信許可（ACK）を受け取る必要がある。
任意に受け付けるのを行わないことで、状態数を減らせる。
だそうです。
Xerox の論文へのリンクも載ってました：
http://mirrors.ccs.neu.edu/MOO/papers/JupiterWin.ps
Yasushi Shinjo
In article <gvvvbl$jmd$1...@aioe.org>
tesi...@diary.ocn.ne.jp (tesi...@diary.ocn.ne.jp) writes:
> こんな記事がありました：
> http://www.atmarkit.co.jp/news/200906/01/wave.html
> 「開発チームが明かす、Google Waveの実装概要」
> Xerox の論文へのリンクも載ってました：
> http://mirrors.ccs.neu.edu/MOO/papers/JupiterWin.ps
情報ありがとうございます。面白い記事ですね。
> ・メールシステムを作り直すとしたらどうやるかという問題意識でスタートした
なるほどね。オフラインも出きるんですね。メールというと、今の
SMTP はスパム問題を抱えているのので、単純に、SMTP <-> Google
Wave のゲートウェーを作ると、Google Wave にスパムが入ってく
るだけなので、それは何とかしないといけないですね。
> ・矛盾が起こらないようにするため、Waveでは各操作を変換する
> 「オペレーション変換」を実装している
...
> ・クライアントから操作（差分）を送るときに
> サーバから明示的に送信許可（ACK）を受け取る必要がある。
> 任意に受け付けるのを行わないことで、状態数を減らせる。
この辺りの、クライアント・プログラムから見たときの実装はがん
ばっている感じがします。
クライアント・プログラムはいいとして、それを操作している人間
がどう見えるのかという問題は、残っているのだと思います。単純
化してオフラインで DOM 木とかディレクトリ木を複数人で編集し
ていると、CVS の conflict の問題が出てくるんじゃないかと。ま
あ、人間と人間の間のプロトコルの問題なのでシステムの方として
はほっとくしかないのかもしれないけれど。
Ａさんが、ある領域をエデットしていて、Ｂさんがその領域をカッ
トしたとして、マージしてカットの勝ちにするのはいいけれど、Ａ
さん怒るでしょうね。Ａさんのテキスト・エディタから、どう見え
るのがいいのか。