我正在編寫一個應用程序，其中我想要近乎實時的文檔協作編輯功能（非常類似於Google文檔樣式編輯）。實時協作編輯 - 它是如何工作的？
我知道如何跟蹤光標位置，這很簡單。只需使用當前的用戶標識，文件名，行號和可存儲在數據庫中的行號輪詢服務器半秒或秒，並且此輪詢請求的返回值是其他用戶光標的位置。
我不知道該怎麼做是以這樣一種方式更新文檔，它不會拋開光標並強制完全重新加載，因爲這對我的目的來說會很慢。
這真的只能在谷歌瀏覽器中工作，最好是Firefox。我不需要支持任何其他瀏覽器。
在幕後用於合併來自多個對等方的協作編輯的算法稱爲operational transformation。儘管這不是微不足道的。
另請參閱this question有用的鏈接。
Google Docs團隊對實時協作如何工作做了一些案例研究，但找不到博客條目。
有維基百科的頁面上一些體面的東西，雖然： http://en.wikipedia.org/wiki/Collaborative_real-time_editor
由於Gintautas指出，這是由操作轉換完成。據我瞭解，這項功能的研究和開發大部分是作爲現已解散的Google Wave項目的一部分完成的，被稱爲Wave協議。幸運的是，Google Wave是開源的，所以你可以在http://code.google.com/p/wave-protocol/
OT研究和開發的大部分工作都是在80年代後期完成的。 – 2013-03-11 00:59:48
得到一些很好的代碼示例。你不需要xmpp或wave。大多數關於開源實現的工作，名爲infinote已經用jinfinote完成（https://github.com/sveith/jinfinote）。 Jinfinote最近也被移植到python（https://github.com/phrearch/py-infinote）來集中處理併發和文檔狀態。我目前使用hwios項目（https://github.com/phrearch/hwios），這依賴於websockets和json傳輸。你不想真的想使用輪詢這些類型的應用程序。另外xmpp似乎使事情變得複雜化，不必要的imo。
對於想要在瀏覽器中實現此功能的用戶，您可以通過+1獲取Jinfinote的鏈接。 – 2013-06-03 18:55:31
在談到這個問題並做了更仔細的搜索之後，我認爲最好的獨立應用程序是Etherpad，它作爲JS瀏覽器應用程序運行並在服務器端使用Node.js。背後的技術被稱爲operational transformation。
Etherpad最初是一個非常重量級的應用程序，它被谷歌收購併納入Google Wave，失敗了。該代碼以開源形式發佈，並且該技術在Etherpad Lite的JavaScript中重寫，現在只更名爲「Etherpad」。一些Etherpad技術可能也被整合到Google Docs中。
由於EtherPad的，已經有各種版本使用新技術，特別是一些JavaScript庫，允許這種直接整合到您的Web應用程序：
我meteor-sharejs包的維護人員，用於將實時編輯者直接添加到Meteor應用程序，其中恕我直言，是兩全其美的:)
實時協作編輯需要幾件事情才能奏效。這裏的其他大多數答案都只關注問題的一個方面。即分佈式狀態（又名共享可變狀態）。操作轉換（OT），無衝突複製數據類型（CRDT），差分同步以及其他相關技術都是實現近實時分佈式狀態的方法。大多數注重於最終的一致性，這允許每個參與者暫時的分歧狀態，但是保證每個參與者狀態最終會在編輯停止時收斂。其他答案提到了這些技術的幾種實現。
但是，一旦您共享了可變狀態，您需要其他幾項功能來提供合理的用戶體驗。這些額外的概念的例子包括：
共享遊標和選擇是協作提示（a.k.a Collaboration Awareness）的例子。它們幫助用戶理解其他參與者的意圖和可能的下一個行動。原始的海報部分地詢問了共享可變狀態與協作提示之間的相互作用。這很重要，因爲文檔中光標或選擇的位置通常是通過文檔中的位置來描述的。問題在於遊標的位置（例如）取決於文檔的上下文。當我說我的光標位於索引37時，這意味着我正在查看的文檔中的字符37。由於您或其他用戶的修改，您現在可能擁有的文檔可能與我的文檔不同，因此文檔中的索引37可能不正確。
因此，您用來分配遊標位置的機制必須以某種方式集成到或至少知道系統的機制，該機制通過共享的可變狀態提供併發控制。今天的挑戰之一是，雖然有很多OT/CRDT，雙向消息傳遞，聊天和其他庫，但它們是沒有集成的隔離解決方案。這使得構建能夠提供良好用戶體驗的最終用戶系統變得很困難，並且往往會給開發人員帶來技術挑戰。
最終，爲了實現有效的實時協作編輯系統，您需要考慮所有這些方面;我們甚至沒有討論過歷史，授權，應用程序級別衝突解決方案和其他許多方面。您必須以適合您的用例的方式構建或查找支持這些概念的技術。然後你必須整合它們。
好消息是，支持協作編輯的應用程序變得越來越流行。支持構建它們的技術正在成熟，並且每個月都有新的技術可用。 Firebase是第一批嘗試將這些概念中的許多概念包裝成易於使用的API的解決方案之一。新來者Convergence（完全披露，我是Convergence Labs的創始人）提供了一個全功能於一身的API，支持大多數這些協作編輯方面，並且可以顯着減少構建實時時間，成本和複雜性協作編輯應用。
我最近出版了什麼，似乎你想實現一個工作示例存儲庫：
https://quill-sharedb-cursors.herokuapp.com
它基於關閉ShareDB（OT）工作作爲後端和Quill富文本編輯器在前端。
基本上只是用some more code to draw the cursors連接所有這些東西。代碼應該很容易理解並複製到任何特定的解決方案。
希望它有助於努力。
因此，如果我要使用http://code.google.com/p/google-diff-match-patch/，並說每0.5秒產生一個差異，請將其發送到服務器並將所有其他差異並從服務器返回它們，你認爲這會起作用嗎？這不會增加存儲在數據庫中的大量數據嗎？ – 2011-02-23 03:51:17
與實際運營轉型相比，它在資源方面可能要貴很多。我想如果你的用戶很少的話就可以解決問題。 – 2011-02-23 09:12:01
如果您正在尋找運營轉型的實施，我建議您查看Google-MobWrite（鏈接可以在鏈接問題中找到）。 – gamers2000 2011-04-23 02:56:11