3

これは単純で実用的な答えを伴う質問ではなく、リアルタイム データ交換のトピックに関する議論を促進するための質問です。

例から始めます：

Google Wave の中核は、リアルタイムの非同期データ同期エンジンです。Wave は、同時 (リアルタイム) ドキュメント コラボレーション、切断された (オフライン) ドキュメント編集、競合の解決、ドキュメント履歴と属性による再生、およびサーバー フェデレーションをサポートしています (またはサポートする予定です)。

Wave のコア部分は運用変換エンジンです: http://www.waveprotocol.org/whitepapers/operational-transform

OT エンジンはドキュメントの状態を管理します。クライアント間の変更はマージされ、各クライアントは常にドキュメントの正常で一貫したビューを持っています。最終的なドキュメントは、接続されているすべてのクライアント間で最終的に一貫しています。

私の質問は次のとおりです。このシステムは、各クライアントでリアルタイムの非同期状態を同期する Web アプリを構築するためのライブラリまたは汎用フレームワークとして使用するのに十分抽象的または一般的ですか?

Wave プロトコルは現在の Web アプリケーション (Google のクライアントを除く) で直接使用されていますか? Web アプリで一般的な状態の同期に直接使用することは理にかなっていますか?

このような Web アプリを構築する際に、他にどのような既存のライブラリまたはフレームワークを使用することを検討しますか?

このようなアプリのコードのうち、ドメイン固有のロジックと一般的な状態同期ロジックのコードの量はどれくらいですか? または、別の言い方をすれば、状態同期の抽象化はどの程度漏れやすいのでしょうか?

コメントや議論を歓迎します!

4

4 に答える 4

1

Jack Moffitt の著書「Professional XMPP Programming with JavaScript and jQuery」は、運用変換ビットを含め、まさにこの質問に対する答えを提供します。

于 2010-04-15T20:24:03.397 に答える
1

OT の実装に関する限り、Wave は実際には骨抜きにされており、文献で説明されている OT の約束を果たすことができません。Jupiter 共同システムに基づいているため、クライアント/サーバー ネットワーク トポロジに限定されます。Google はさらに Jupiter OT アルゴリズムを妨害して、特定のクライアントによる「実行中」の操作の数を 1 つに制限しました。これは、クライアント間の対話性を大きく損ないます。

Wave はどの程度「一般的」ですか? 私がコードを思い出す限り、これは Wave データ モデル (ブリップ、注釈など) にかなり関連付けられているようです。したがって、重大な変更を加えずに他のデータ モデルに適用することは難しいと思います。

さらに、Wave ベースのシステムのスケーラビリティと堅牢性にも関心があります。たとえば、特定の Wave で操作を処理できるのは 1 つのサーバーのみであり、サーバーのロールバックは非常に壊滅的であり、すべてのクライアントが Wave を破棄する (未処理の操作を含む) ため、フェイルオーバー サポートを実装する方法が明確ではありません。 .

Wave は積極的に開発中であるため、時間の経過とともに改善されます。

Wave に代わるものはあまりありません。この質問への回答で述べたように、私は OT ベースの同期に Ceda を使用しています。Ceda には「漏れやすい抽象化」の問題はありません。OT を使用して任意のデータ構造を同期できます。アプリケーションがスキーマを定義します。

于 2010-07-28T09:03:10.167 に答える
0

これはPubSubHubbubのようなもので実現でき、非常に簡単だと思います。仕組み：両方のシステムには、データを表すRSS / Atomフィード、または少なくとも「URLXYZで作成されたオブジェクト」などのデータのイベントが必要です。

次に、両方のフィードでPubSubHubbubが有効になっていることを確認します。これは、コンテンツが更新されたときにサブスクライバーに通知できることを意味します。

各コンポーネントを他のコンポーネントのフィードにサブスクライブします。

通知時に何が起こるかを実装します：ファイルのダウンロード、データベース内のものの更新...あなたはそれに名前を付けます。

これの大きな利点は、 「既知」のもの（HTTP、ATOM）のみに依存することです。

このブログ投稿はソーシャルデータの例を示していますが、それはあらゆるタイプのデータにも当てはまります。

于 2010-04-30T17:05:50.203 に答える
0

クライアントからサーバーへの呼び出しを処理するために HTTP が作成されましたが、これはPush Technologyが必要な場合の問題です。私は Web 開発者なので、Cometを使用します。

ブラウザーはサーバーに対して Ajax スタイルの要求を行います。この要求は、サーバーがブラウザーに送信する新しいデータを取得するまで開いたままになり、完全な応答でブラウザーに送信されます。ブラウザは、後続のイベントを取得するために、新しいロング ポーリング リクエストを開始します。

Lift と呼ばれる Web 開発フレームワークを使用して、Comet スタイルの Web アプリケーションを構築できます。(これは、Java バイトコードにコンパイルされる Scala と呼ばれるプログラミング言語で書かれているため、Java アプリケーション サーバーで実行できます。)

HTML5 には、Web ソケットと呼ばれる機能があり、Comet が廃止される可能性があります。

于 2010-04-19T04:45:22.093 に答える