問題タブ [operational-transform]

Google Docs のようなアプリや、ShareJSやEtherPad Liteのようなライブラリを見てきて、私はリアルタイムのコラボレーションに非常に興奮しています。これは、Operational Transformation として知られる非常に複雑な手法を使用して実装されているようです。

私の質問はおそらくやや奇妙です: なぜ OT が必要なのですか?

つまり、ほとんどの設定で Web のレイテンシが非常に低いということです。Google Docs、ShareJS、EtherPad などのツールを使用すると、変更は接続されたクライアントにほぼ瞬時に反映されます。

競合を解決し、サーバー側で同期を維持するための非常に複雑なソリューションはなぜですか?

コマンドパターンと元に戻す/やり直しに精通しているので、ドキュメントへのすべての変更を、同等の元に戻すコマンドを使用したコマンドとして単純に実装することが、はるかに簡単な解決策のように思えます。

クライアントが変更を加えたときにシリアル化されたコマンドを送信できるようにします。受信したすべてのコマンドにサーバー側でシリアル番号を割り当てます。ドキュメントに適用されたすべてのコマンドをクライアントに配布し、コマンドの履歴も保持します。

接続された各クライアントは、ドキュメントに適用されたすべてのコマンドをサーバーから受信します。これには、「正しい」順序、たとえばコマンドがサーバーによって受信され、マスター ドキュメントに適用された順序を示すシリアル番号が付けられます。サーバーによって保持されます。

クライアントがコマンド番号 100 であった場合、番号 102 として返される新しいコマンドをサーバーに送信すると、クライアントはコマンドを見逃したことを認識します。次に、送信した最後のコマンドに対して「元に戻す」コマンドを適用するだけです。コマンド番号 101 を適用し、それ自体のコマンド番号 102 を再度適用して、順序を元に戻します。

いくつかのコマンドが遅れている場合は、必要なだけロールバックしてから、見逃したすべてのコマンドを適用するなどします。

それは私にはずっと簡単に聞こえます。

それよりも運用の変革が優れている点は何ですか?

Sharejs を使用して共同テキスト エディターを作成しようとしていますが、最初はいくつかの問題に直面しています。

私は「はじめに」ページから始めました。をnpm install share使用してサンプルサーバーを実行してから実行し./node_modules/share/bin/exampleserverました。これはうまくいきます。

ただし、「サーバーの実行」セクションの手順に従って、独自の小さなアプリケーションを作成してみました。app.js ファイルと推奨される html を作成しました。これを実行しようとすると、ブラウザ コンソールに socket.io.js が見つからないという 404 エラーが表示されます。

そして、このエラーが繰り返し発生します：

これを引き起こしている提案やアイデアはありますか? 前に述べたように、事前構成された例はローカルでうまく機能するため、それが機能することはわかっていますが、新しいアプリを作成しようとしているときに何かを正しく構成してはいけません.

ありがとう。

Pedestalのプレゼンテーションを読む(およびサンプル ソース コードを読む) - 変換と操作に基づくモデルが表示されます。

Pedestalが、 Google Waveで使用されたものと同様の運用上の変換 (こことここを参照) を使用するというのは本当ですか?

Meteor でアプリを構築したとき、その機能には本当に驚かされました。ただし、Etherpad スタイルの共同編集ビットをアプリにドロップできるようになれば、本当に最高の目標です。

これを行う方法を調べているときに、meteor で OT ライブラリを使用していると思われるプロジェクトをいくつか見つけました。

ot.jsを使用するプロジェクト:

• https://github.com/TeamCocoDojo/cocodojo ( http://cocodojo.meteor.comでデモ)

ShareJSを使用するプロジェクト:

• https://github.com/mad-eye/meteor-sharejs ( http://madeye.io/でデモ)

これらのプロジェクトが Meteor とどのように統合されているかはわかりません。彼らは実際に Meteor Collections を使用していますか? Meteor をホストしているノード サーバーを使用し、OT を別のコンポーネントとして実行し、Meteor をまったく使用しないのでしょうか? Meteor との統合に優れた別の OT ライブラリはありますか?

これらのプロジェクトに詳しい方、または Meteor アプリの一部として OT を実装したことがある方は、これにアプローチする最善の方法についてご意見をお聞かせください。

(これはMeteor.js の運用変換の複製ではありませんか?その質問はほぼ 1 年前のものであり、Meteor はそれ以来長い道のりを歩んできました。)

HTML-Content のような contenteditable-Elements とsharejsを一緒に使用する方法はありますか?<div contenteditable="true">Content <b>with html</b></div>

または、HTML コンテンツまたはリッチテキストと組み合わせた運用変換 (OT) の他のベスト プラクティスはありますか? これはnode.jsでどのように行うことができますか?

私はMeteorにかなり慣れていませんが、面白いと思いました。

Meteor がリアルタイムで同時実行制御を行うために使用する基本的な手法またはアルゴリズムは何ですか? また、それが競合に対してどのように機能するのでしょうか? オペレーショナル トランスフォーメーション (OT) に基づいているのか、それとも他の何かに基づいているのか? また、Meteor のアーキテクチャを知っておくと役立ちます。

Operational Transform と CRDT の主な違いを簡単に説明してもらえますか?

私が理解している限り、どちらも分散システムの異なるノードで競合することなくデータを収束させるアルゴリズムです。

どのユースケースでどのアルゴリズムを使用しますか? 私の知る限り、OTは主にテキストに使用され、CRDTはより一般的で、より高度な構造を正しく処理できますか?

CRDT は OT よりも強力ですか?

私がこの質問をするのは、HTML 文書用の共同エディターを実装する方法を調べようとしていて、最初にどの方向を見ればよいかわからないからです。私は、ShareJS プロジェクトと、ブラウザ上でcontenteditables要素のリッチ テキスト コラボレーションをサポートしようとする試みを見ました。ShareJSのどこにも、そのためにCRDTを使用しようとする試みは見られません。

また、Google Docs が OT を使用していることもわかっており、リッチ ドキュメントのリアルタイム編集に非常にうまく機能しています。Google が OT を選択したのは、当時 CRDT があまり知られていなかったからですか? それとも今日も良い選択でしょうか？

データベースでこれらのアルゴリズムを使用するなど、他のユースケースについても知りたいです。Riak は CRDT を使用しているようです。OT を使用してデータベースのノードを同期し、Paxos/Zab/Raft の代わりにすることはできますか?

現在、xml ファイルに状態を保存およびロード (シリアル化) できるアプリケーション (ダイアグラム エディター) があります。

ここで、このアプリケーションを Microsoft OneNote アプリケーションのように動作させたいと考えています。複数のユーザーが同じファイルにアクセスできる場所。

後で、(1) 何が変更され、誰が変更したか、(2) 競合があればそれを解決するオプションなど、他のことを強化する必要があるかもしれません。

これを解決する同期フレームワークについて知りました。これまでのところ、私はそれを試していません。

私が欲しいのは、

1. 実質的に単一のファイルは、同じアプリケーションの複数のインスタンスで編集する必要があります。

2. 以下を実行する dll (同期フレームワーク) が必要です。

   • ファイル処理の完全な責任を負います。
   • この dll を使用して、アプリケーションの各インスタンスは独自の変更を通知します。
   • アプリケーションの各インスタンスには、最近行われた変更 (いつ、誰が、どのような変更を行ったか) を検出する機能が必要です。

私の質問：

1. 同期フレームワークはこの要件に適していますか?
2. もしそうなら、これを表すデモアプリケーションはありますか?

私は、Google Docs に似た機能 (複数の人が同時に作業できるようにする) を備えた、独自の Javascript エディターを作成することをいじっています。私が理解していないことの1つ：

ユーザー A とユーザー B が 10 ミリ秒のネットワーク遅延で互いに直接接続されているとします。私は、編集が「インデックス 3 に「テキスト」を挿入」のように表される diff システム (Docs が行っていることを理解している) をエディターが使用していると仮定しています。

「xyz123」というテキストを含むドキュメントから始めましょう。

ユーザー A はタイムスタンプ 001ms でドキュメントの先頭に「abc」と入力し、ユーザー B はタイムスタンプ 005ms で「xyz」と「123」の間に「hello」と入力します。

どちらのユーザーも、結果が「abcxyzhello123」になることを期待しますが、ネットワークの遅延を考慮すると、次のようになります。

• ユーザー B は、時間 011ms にユーザー A の「インデックス 0 に 'abc' を挿入」の編集を受け取ります。時系列の順序を維持するために、ユーザー B はユーザー B のインデックス 3 での挿入を元に戻し、ユーザー A の「abc」をインデックス 0 で挿入し、次にユーザー B のインデックス 3 での挿入を再挿入します。これは現在「abc」と「xyz」の間にあります。 、」したがって、「abchelloxyz123」が得られます
• ユーザー A は、時間 015ms にユーザー B の「インデックス 3 に「hello」を挿入」の編集を受け取ります。ユーザー B の挿入がユーザー A の後に行われたことを認識し、インデックス 3 (現在は "abc" と "xyz" の間) に "hello" を挿入するだけで、"abchelloxyz123" となります。

もちろん、「abchello xyz123」は「 abc xyz hello 123」と同じではありません。

文字通りすべてのキャラクターに独自の一意の ID を割り当てる以外に、Google がこの問題を効果的に解決する方法を想像することはできません。

私が考えたいくつかの可能性：

• ユーザー B が編集前に挿入ポイントを 1 ミリ秒移動した場合、まったく同じ問題が発生することを除いて、差分を含むインデックスを送信する代わりに挿入ポイントを追跡することは機能します。
• ユーザー B に、「'xyz' の後に挿入」などの情報を diff で送信してもらい、ユーザー A がこれが発生したことをインテリジェントに認識できるようにすることもできますが、ユーザー A がテキスト「xyz」を挿入するとどうなるでしょうか。
• ユーザー B は、これが発生したことを認識し (ユーザー A の diff を受信し、それが競合していることを確認すると)、ユーザー B の編集を元に戻す diff と、ユーザー B の "hello" "abc".length インデックスをさらに挿入する新しい diff を送信します。右。これに関する問題は、(1) ユーザー A がテキストに「ジャンプ」を表示すること、および (2) ユーザー A が編集を続ける場合、ユーザー B は継続的に差分を修正する必要があることです。修正する必要があり、複雑さが指数関数的に増加します。
• ユーザー B は、最後に受信したタイムスタンプ付きの diff が -005ms か何かであるというプロパティを diff と共に送信できます。その後、A は B がその変更について知らなかったことを認識し (A の diff は 001ms であったため)、競合の解決を行うことができます。問題は、(1) ほとんどのコンピューターの時計がミリ秒単位で正確ではないことを考慮すると、すべてのユーザーのタイムスタンプがわずかにずれることと、(2) ユーザー A との遅延が 25 ミリ秒でユーザー B との遅延が 2 ミリ秒の 3 番目のユーザー C が存在する場合、ユーザー C が -003ms で「x」と「y」の間にテキストを追加すると、ユーザー B はユーザー C の編集を参照点として使用しますが、ユーザー A はユーザー C の編集については知りません (したがって、ユーザー B の参照点) 22msまで。共通のサーバーを使用してすべての編集にタイムスタンプを付ければ、これは解決できると思いますが、それはかなり複雑なようです。
• 各キャラクターに一意の ID を与え、インデックスの代わりにそれらの ID を使用することもできますが、それはやり過ぎのように思えます...

http://www.waveprotocol.org/whitepapers/operational-transformを読んでいますが、この問題を解決するためのあらゆるアプローチを聞きたいです。

私は短い間Quillを使用しており、共同編集を機能させることに集中してきました。これまでのところ順調に進んでおり、完全に機能する共同編集者がいます!

他のユーザーの選択範囲とカーソル位置を表示したいのですが、Quill でこの問題に適切にアプローチする方法が思いつきません。

私は基本的に、実際のドキュメント モデルにコンテンツを追加せずに、レンダリングされたドキュメントにマークアップを追加したいと考えています。これは可能ですか？どこから始めればよいですか？