我正在编写一个应用程序，其中我想要近乎实时的文档协作编辑功能（非常类似于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