共同作業可能なリアルタイムエディタ

共同リアルタイム エディターは、共同作業ソフトウェアまたはWeb アプリケーションの一種であり、異なるコンピューターまたはモバイル デバイス上の異なるユーザーが同時に、同じデジタル ドキュメント、コンピューター ファイル、またはクラウドに保存されたデータ(オンライン スプレッドシート、ワード プロセッサドキュメント、データベース、プレゼンテーションなど) のリアルタイム共同編集、同時編集、またはライブ編集を可能にし、編集内容を自動的にほぼ瞬時にマージします 。

リアルタイム編集では、オンライン ユーザーが自分のデバイスでドキュメントを編集するときに、すべてのオンライン ユーザーの編集内容が自動的かつ定期的に、多くの場合ほぼ瞬時に同期されます。これは、編集の競合を回避または最小限に抑えるように設計されています。

非同期の共同編集（つまり、非リアルタイム、遅延、またはオフライン）では、各ユーザーは通常、手動で編集を送信（公開、プッシュ、またはコミット）、更新（更新、プル、ダウンロード、または同期）、および（編集の競合が発生した場合）マージする必要があります。非同期の共同編集の遅延の性質により、複数のユーザーが同じ行、単語、要素、データ、列、またはフィールドを編集することになり、編集の競合が発生して、手動で編集をマージまたは上書きする必要が生じ、ユーザーはどの編集を使用するかを選択する必要があります。または、（システムと設定に応じて）警告の有無にかかわらず、自分の編集または他のユーザーの編集を自動的に上書きします。

共同リアルタイム エディターの最初の例は、 1968 年にDouglas EngelbartによってThe Mother of All Demosで実証されました。このコンセプトが広く利用できる実装が登場するまでには数十年かかりました。

1991年にON Technology社からクラシックMac OS向けにInstant Updateと呼ばれるソフトウェアがリリースされました。^{[1] [より詳しい情報源が必要]このソフトウェアは、} LAN経由で複数のユーザーが1つの文書をリアルタイムで編集することを可能にし、ワークグループサーバーに依存していました。

インターネットを介したリアルタイムの共同編集への関心から、2003 年から 2005 年にかけてMoonEditとSubEthaEditが開発され、その後すぐにGobbyが開発されました。

Ajax技術とブラウザの「コンテンツ編集可能」機能の導入により、2005 年頃のWeb 2.0現象の一環として、Web ベースのリアルタイム共同編集が発展しました。特に、Writelyと呼ばれる製品は爆発的なユーザー数の増加が見られ、2006 年 3 月に Google に買収されました (これは後にGoogle Docsとして知られるようになり、後にGoogle Driveに改名されました)。この製品は、文書全体の同時編集を可能にしましたが、他のユーザーによる変更は、クライアント プログラムがサーバーをポーリングした後 (約 30 秒ごと) にのみ反映されました。^[要出典]初期の Web ベースのソリューションとしては他に、JotSpotLive があり、行単位の同時編集がほぼリアルタイムで可能でした。^[2]しかし、2006 年 11 月に Google が親会社 ​​JotSpot を買収した後、このサイトは閉鎖されました。Google Sites は2007 年 2 月に JotSpot のリファクタリングとして開始されましたが、^{[3] [4] [5] [6]}、JotLive のようなマルチユーザーリアルタイム機能がありません。Synchroedit (リッチテキスト) と MobWrite (プレーンテキスト) プロジェクトは、リアルタイムのブラウザベースの共同編集のギャップを埋めるための、より最近の^{[いつ? ]}オープンソースの試みですが、特に大規模なアーキテクチャでは、真のリアルタイムパフォーマンスを実現できていません。^{[引用が必要]}

2009年、Googleはリアルタイムコラボレーション環境であるGoogle Waveのベータテストを開始しました。Googleはこれが最終的に電子メールやインスタントメッセージングに取って代わることを期待していました。 ^[要出典] EtherPadはGoogleに買収され、EtherPadチームはWaveプロジェクト内での作業に割り当てました。しかし、Googleは2010年8月にブログ^[7]で、ユーザーからの採用が不十分だったため、Waveをスタンドアロンプ​​ロジェクトとして開発することを中止することを決定したと発表しました。2009年12月にGoogleが放棄されたEtherPadのソースコードをオープンソースとしてリリースした後、コミュニティが開発を引き継ぎ、完全にJavaScriptで記述され、 Node.js上に構築されたEtherpad liteという完全な書き直しを作成しました。運用変革技術に基づくもう1つの注目すべきツールはCKEditorです。^[8] 2020年には、Microsoftも最近、OTやCRDTではなく、新しいTotal Order Broadcast技術に依存するFluid Frameworkをリリースしたため、このコンセプトへの関心が高まっています。 ^[9] Fluidは現在フレームワークに依存しません。Microsoftは、まだ本番環境での使用には準備ができていないと述べています。^[10]

2016年6月、Collabora Productivityは、 LibreOfficeテクノロジーを使用したオープンソースのオンラインオフィススイートであるCollabora OnlineのV1.0をリリースしました。これは、数行のコードであらゆるWebサイトに統合できます。ソフトウェア開発キットには、 Node.js、PHP、Python、ReactJS、.NETのサンプル統合コードが用意されており、カスタマイズ可能なユーザーインターフェイスとの相互運用可能な統合を可能にするAPI仕様があります。^{[11] [12] [13]} Collabora Onlineを使用すると、ドキュメントはサーバー上に残り、各ユーザーが同時に同じドキュメントを共有して、他のユーザーの入力を確認するための余分なラグやレイテンシなしに、1つのドキュメントだけをリアルタイムでインタラクティブに編集できます。テキストドキュメント内の段落をロックする必要がなくなります。ワープロ文書、スプレッドシート、プレゼンテーション、描画、ベクターグラフィックスのリアルタイムの共同編集が可能になります。

最近^{[いつ? ]}、リアルタイムの共同編集は、2020年にリリースされた AtomとVisual Studio Code^{の拡張機能を備えたスタンドアロンのテキスト編集アプリケーションに戻ってきました。 [14] [15]}

リアルタイムの共同編集は、ウェブ上のMicrosoft Office（旧称Office Online）などのウェブアプリケーションでオンラインで行うことができます。Microsoft Officeは、 Office.com、OneDrive、SharePointクラウドストレージに保存されているWord文書、Excelスプレッドシート、PowerPoint、その他のMicrosoft Office文書のオンライン（ウェブベース）同時編集（Microsoftでは「共同編集」と呼んでいます）をサポートしています。また、 Googleドキュメントやその他のGoogle Workspace生産性向上（オフィススイート）アプリでは、Google Driveに保存されているワープロ文書やその他の文書のオンライン共同編集が可能です。リアルタイムの共同編集は、Power Sheet BI for Excel ^[16]などのハイブリッドな方法でも行うことができ、デスクトップソフトウェアだけでなく、ウェブベースやモバイルアプリでもオフライン、ウェブベース、オンラインの共同編集が可能で、自動的に同期してバージョン履歴に即座にアクセスできます。 2020年には、特にビジネスユースケースにおいて、これらのアプリケーションを安全なウェブアプリケーションに組み込むことへの関心が再燃しており、マイクロソフトとVaadinが、開発者がAPIを通じて利用できるリアルタイム同期データ共有の複雑さを処理する特殊なリアルタイムコラボレーションバックエンドでリードしています。^{[17] [18]} Mozillaは2013年にJavaScriptライブラリTogetherJSをリリースしました。これは、メッセージングシステムとオプションでフォーム同期用の操作変換アルゴリズムを介して、あらゆるウェブアプリケーションにリアルタイムの共同編集機能を追加します。^[19]

VaadinプラットフォームのベンダーであるVaadin Ltd.は、2020年10月にコラボレーションエンジンのV1.0をリリースしました。^[20]これは、開発者が数行のコードを使用して、Javaバックエンドを備えたあらゆるWebアプリケーションにリアルタイムのコラボレーションおよび編集機能を迅速に構築できるようにすることを前提としています（特定のユースケースでは、まだ制限のある高レベルAPIを介して）。^[21]この機能は現在Javaをサポートしていますが、ベンダーは、Vaadinプラットフォームが最近継続的に拡張し、今後Fusionフレームワークを通じてTypeScriptベースのUI構築も可能にすることに合わせて、TypeScriptベースのAPIも登場すると述べています。^{[22] [23]}

リアルタイムの共同編集ソリューションの複雑さは、通信の遅延に起因します。理論上、通信が瞬時に行われる場合、リアルタイムの共同エディターの作成は、シングルユーザー エディターの作成と同じくらい難しくありません。これは、次のようなアルゴリズムを使用してドキュメントを編集できるためです。

1. サーバーから「ドキュメント編集」トークンをリクエストする
2. サーバーがドキュメントを編集する順番を知らせるまで待ちます
3. ドキュメントの編集方法をサーバーに伝える
4. 「ドキュメント編集」トークンを解放する

しかし、通信速度はネットワークの遅延によって制限されます。これにより、根本的なジレンマが生じます。ユーザーは自分の編集内容をドキュメントに即座に組み込む必要がありますが、即座に組み込むと、通信の遅延により、その編集内容を必然的にドキュメントの異なるバージョンに挿入する必要があります。

この問題を説明する例を挙げます。ボブとアリスがMaryという単語を含む文書から作業を始めたとします。ボブは「M」を削除し、「H」を挿入して単語をHaryに変更します。アリスはボブからの編集を受け取る前に、「r」を削除し、「a」を削除してMyに変更します。ボブとアリスはどちらも、自分のマシンには存在しなかった文書のバージョンに適用された編集を受け取ることになります。

したがって、リアルタイムの共同編集の課題は、元々はローカルには存在しなかったドキュメントのバージョンで作成され、ユーザー自身のローカル編集と競合する可能性のあるリモート ユーザーからの編集を正確に適用する方法を見つけることです。

最も洗練されたソリューションは、サーバーを必要とせず、ロックを使用せず (すべてのユーザーが同時にドキュメントのすべての部分を自由に編集できます)、任意の数のユーザーをサポートする (コンピューターのリソースによってのみ制限されます) 方法でこの問題を解決します。UNA とSubEthaEdit は、このアプローチを採用している 2 つのプログラムの例です。

これらの洗練されたアプローチにより、最高のユーザー エクスペリエンスが実現されますが、基本的な共同エディターはクライアント サーバー モデルでも作成できます。クライアント サーバー シナリオでは、ドキュメントが開かれると、エディター インスタンスの 1 つに共同作業サーバーの役割が割り当てられます。このサーバーは、ネットワークの遅延を決定し、時刻同期サーバーとして機能することで、他のエディターの同期が維持されるようにします。サーバーは、他のユーザーがドキュメントに加えた変更のタイムスタンプ付き通知を受け取ります。サーバーは、それらの変更がローカル コピーにどのように影響するかを決定し、その変更を共同作業プールにブロードキャストします。一部のモデルでは、それらの変更がローカルで行われた場合でも、サーバーから正式な応答が返されるまで、変更はクライアントに反映されません。

このアプローチは、それほど強力ではありませんが、比較的低コストで基本的なコラボレーションを可能にします。そのため、処理リソースが限られている状況ではこのアプローチが適しています。NetSketch は、こ​​のモデルを使用するプログラムの例です。

過去に、マイクロソフトとIBMは、既存のアーキテクチャにコラボレーション機能を追加する取り組みを行ってきました。^[24] リアルタイムコラボレーションとして販売されていますが、これらの「ワークスペース」アプローチでは、ドキュメントのロック（一度に1人しか編集できないようにする）または競合する変更の「調整」が必要であり、これは通常、ユーザーに満足のいくものではありません。^[要出典]

• 共同ブラウジング
• 競合のない複製データ型
• 分散コンピューティング
• 分散バージョン管理
• ドキュメントの共同作業
• コラボレーションソフトウェアのリスト
• リアルタイムテキスト
• ウィキ