Javascript 实时协作编辑 - 它是如何工作的？

Real time collaborative editing - how does it work?

提问by Brandon Wamboldt

I'm writing an application in which I'd like to have near real time collaborative editing features for documents (Very similar to Google Documents style editing).

我正在编写一个应用程序，我希望在其中具有近乎实时的文档协作编辑功能（非常类似于 Google 文档样式编辑）。

I'm aware of how to keep track of cursor position, that's simple. Just poll the server ever half second or second with the current user id, filename, line number and row number which can be stored in a database, and the return value of this polling request is the position of other user's cursors.

我知道如何跟踪光标位置，这很简单。每隔半秒或一秒用数据库中可以存储的当前用户ID、文件名、行号和行号轮询服务器，并且该轮询请求的返回值是其他用户的游标位置。

What I don't know how to do is update the document in such a way that it won't throw your cursor off and force a full reload as that would be far to slow for my purposes.

我不知道该怎么做是以这样一种方式更新文档，它不会让您的光标离开并强制完全重新加载，因为这对于我的目的来说太慢了。

This really only has to work in Google Chrome, preferably Firefox as well. I don't need to support any other browser.

这真的只需要在谷歌浏览器中工作，最好是火狐浏览器。我不需要支持任何其他浏览器。

采纳答案by Gintautas Miliauskas

The algorithm used behind the scenes for merging collaborative edits from multiple peers is called operational transformation. It's not trivial to implement though.

在幕后用于合并来自多个对等方的协作编辑的算法称为操作转换。不过，实施起来并非易事。

See also this questionfor useful links.

另请参阅此问题以获取有用的链接。

回答by Phrearch

You don't need xmpp or wave for this necessarily. Most of the work on an opensource implementation called infinote already have been done with jinfinote ( https://github.com/sveith/jinfinote). Jinfinote was recently also ported to python ( https://github.com/phrearch/py-infinote) to handle concurrency and document state centrally. I currently use both within the hwios project ( https://github.com/phrearch/hwios), which relies on websockets and json transport. You don't want really want to use polling for these kind of applications. Also xmpp seems to complicate things unnecessarily imo.

为此，您不一定需要 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 似乎不必要地使事情复杂化。

回答by Michael MacFadden

Real time collaborative editing requires several things to be effective. Most of the other answers here focus on only one aspect of the problem; namely distributed state (aka shared-mutable-state). Operational Transformation (OT), Conflict-Free Replicated Data Types (CRDT), Differential Synchronization, and other related technologies are all approaches to achieving near-real-time distributed state. Most focus on eventual consistency, which allow temporary divergences of each of the participants state, but guarantee that each participants state will eventually converge when editing stops. Other answers have mentioned several implementations of these technologies.

实时协作编辑需要几个条件才能有效。这里的大多数其他答案只关注问题的一个方面；即分布式状态（又名共享可变状态）。操作转换 (OT)、无冲突复制数据类型 (CRDT)、差分同步和其他相关技术都是实现近实时分布式状态的方法。大多数关注最终一致性，这允许每个参与者状态暂时发散，但保证每个参与者状态在编辑停止时最终会收敛。其他答案提到了这些技术的几种实现。

However, once you have shared mutable state, you need several other features to provide a reasonable user experience. Examples of these additional concepts include:

但是，一旦您共享了可变状态，您还需要其他几个功能来提供合理的用户体验。这些附加概念的示例包括：

• Identity: Who the people you are collaborating with are.
• Presence: Who is currently "here" editing with you now.
• Communication: Chat, audio, video, etc., that allow users to coordinate actions
• CollaborativeCueing: Features that give indications as to what the other participants are doing and/or are about to do.

• 身份：与您合作的人是谁。
• 存在：现在谁在“这里”与您一起编辑。
• 交流：聊天、音频、视频等，允许用户协调行动
• 协作提示：指示其他参与者正在做什么和/或将要做什么的功能。

Shared cursors and selections are examples of Collaborative Cueing (a.k.a Collaboration Awareness). They help users understand the intentions and likely next actions of the other participants. The original poster was partly asking about the interplay between shared mutable state and collaborative cueing. This is important because the location of a cursor or selection in a document is typically described via locations within the document. The issue is that the location of a cursor (for example) is dependent on the context of the document. When I say my cursor is at index 37, that means character 37 in the document I am looking at. The document you may have right now may be different than mine, due to your edits or those of other users, and therefore index 37 in your document may not be correct.

共享光标和选择是协作提示（又名协作意识）的示例。它们帮助用户了解其他参与者的意图和可能的下一步行动。最初的海报部分询问了共享可变状态和协作提示之间的相互作用。这很重要，因为文档中光标或选择的位置通常是通过文档内的位置来描述的。问题是光标的位置（例如）取决于文档的上下文。当我说我的光标位于索引 37 处时，这意味着我正在查看的文档中的字符 37。由于您的编辑或其他用户的编辑，您现在可能拥有的文档可能与我的不同，因此文档中的索引 37 可能不正确。

So the mechanism you use to distribute cursor locations must be somehow integrated into or at least aware of the mechanism of the system that provides concurrency control over the shared mutable state. One of the challenges today is that while there are many OT / CRDT, bidirectional messaging, chat, and other libraries out there, they are isolated solutions that are not integrated. This makes it hard to build an end user system that provides a good user experience, and often results in technical challenges left to the developer to figure out.

因此，您用于分配游标位置的机制必须以某种方式集成到或至少意识到系统的机制中，该机制提供对共享可变状态的并发控制。今天的挑战之一是，虽然有许多 OT/CRDT、双向消息传递、聊天和其他库，但它们是未集成的孤立解决方案。这使得构建提供良好用户体验的最终用户系统变得困难，并且往往导致开发人员需要解决的技术挑战。

Ultimately, to implement an effective real time collaborative editing system, you need to consider all of these aspects; and we haven't even discussed history, authorization, application level conflict resolution, and many other facets. You must build or find technologies that support each of these concepts in a way that make sense for your use case. Then you must integrate them.

最终，要实施有效的实时协作编辑系统，您需要考虑所有这些方面；我们甚至还没有讨论历史、授权、应用程序级别的冲突解决以及许多其他方面。您必须以对您的用例有意义的方式构建或找到支持这些概念中的每一个的技术。然后你必须整合它们。

The good news is that applications that support collaborative editing are becoming much more popular. Technologies that support building them are maturing and new ones are becoming available every month. Firebasewas one of the first solutions that tried to wrap in many of these concepts into an easy to use API. A new-comer Convergence(full disclosure, I am a founder of Convergence Labs), provides an all-in-one API that supports the majority of these collaborative editing facets and can significantly reduce the time, cost, and complexity of building real time collaborative editing apps.

好消息是支持协作编辑的应用程序正变得越来越流行。支持构建它们的技术正在成熟，并且每个月都有新的可用。Firebase是最早尝试将许多这些概念包装成易于使用的 API 的解决方案之一。一个新人Convergence（完全公开，我是Convergence Labs的创始人），提供了一个多合一的API，支持大多数这些协作编辑方面，可以显着减少构建实时的时间、成本和复杂性协作编辑应用程序。

回答by Andrew Mao

After coming upon this question and doing a more careful search, I think the best standalone application to check out would be Etherpad, which runs as a JS browser app and using Node.js on the server side. The technology behind this is known as operational transformation.

在遇到这个问题并进行更仔细的搜索后，我认为最好的独立应用程序是Etherpad，它作为 JS 浏览器应用程序运行并在服务器端使用 Node.js。这背后的技术被称为运营转型。

Etherpad was originally a pretty heavyweight application that was bought by Google and incorporated into Google Wave, which failed. The code was released as open source and the technology was rewritten in Javascript for Etherpad Lite, now renamed just "Etherpad". Some of the Etherpad technology was probably also incorporated into Google Docs.

Etherpad 最初是一个相当重量级的应用程序，被谷歌收购并整合到 Google Wave 中，但失败了。该代码作为开源发布，该技术用 Javascript 为 Etherpad Lite 重写，现在更名为“Etherpad”。一些 Etherpad 技术可能也被整合到 Google Docs 中。

Since Etherpad, there have been various versions to this technology, notably some Javascript libraries that allow for integrating this directly into your web app:

自 Etherpad 以来，该技术已经有了各种版本，特别是一些允许将其直接集成到您的 Web 应用程序中的 Javascript 库：

• ShareJS
• ot.js

• 分享JS
• ot.js

I am the maintainer of the meteor-sharejspackage for adding realtime editors directly to a Meteorapp, which IMHO is the best of both worlds :)

我是meteor-sharejs包的维护者，用于将实时编辑器直接添加到Meteor应用程序中，恕我直言，这是两全其美的:)

回答by StriplingWarrior

As Gintautas pointed out, this is done by Operational Transformation. As I understand it, the bulk of the research and development on this feature was done as part of the now-defunct Google Wave project, and is known as the Wave Protocol. Fortunately, Google Wave is open-sourced, so you can get some good code samples at http://code.google.com/p/wave-protocol/

正如 Gintautas 所指出的，这是通过运营转型来完成的。据我了解，这个功能的大部分研究和开发是作为现已解散的 Google Wave 项目的一部分完成的，被称​​为 Wave 协议。幸运的是，Google Wave 是开源的，因此您可以在http://code.google.com/p/wave-protocol/ 上获得一些不错的代码示例

回答by arnorhs

The Google Docs team did a little bit of a case study around how the real time collaboration worked, but I can't find the blog entry.

Google Docs 团队围绕实时协作的工作原理做了一些案例研究，但我找不到博客条目。

There is some decent stuff on the wikipedia page, though: http://en.wikipedia.org/wiki/Collaborative_real-time_editor

不过，维基百科页面上有一些不错的东西：http: //en.wikipedia.org/wiki/Collaborative_real-time_editor

回答by pedrosanta

I've recently published a repository with a working example of what seems you're trying to achieve:

我最近发布了一个存储库，其中包含一个您正在尝试实现的工作示例：

https://quill-sharedb-cursors.herokuapp.com

https://quill-sharedb-cursors.herokuapp.com

It's based off ShareDB(OT) working as the backend and Quillrich text editor on the frontend.

它基于ShareDB(OT) 作为后端和前端的Quill富文本编辑器。

Basically just wires all these things with some more code to draw the cursors. The code should be fairly simple to understand and to copy over to any specific solution.

基本上只是用一些更多的代码连接所有这些东西来绘制光标。代码应该很容易理解并复制到任何特定的解决方案中。

Hope it helps with the endeavor.

希望它对努力有所帮助。