Совместное редактирование в режиме реального времени - как это работает?

Я пишу приложение, в котором я хотел бы иметь возможности совместного редактирования в режиме реального времени для документов (очень похоже на редактирование стиля документов Google).

Я знаю, как отслеживать позицию курсора, что просто. Просто опробуйте сервер каждые полсекунды или секунду с текущим идентификатором пользователя, именем файла, номером строки и номером строки, который может быть сохранен в базе данных, а возвращаемое значение этого запроса на опрос - это позиция других пользовательских курсоров.

То, что я не знаю, как это сделать, - это обновить документ таким образом, чтобы он не отбрасывал курсор и не приводил к полной перезагрузке, поскольку это было бы очень медленным для моих целей.

Это действительно должно работать только в Google Chrome, предпочтительно в Firefox. Мне не нужно поддерживать какой-либо другой браузер.

Ответ 1

Алгоритм, используемый за кулисами для слияния коллективных изменений от нескольких одноранговых узлов, называется операционная трансформация. Это не тривиально реализовать.

См. также этот вопрос для полезных ссылок.

Ответ 2

Вам не нужно xmpp или волна для этого обязательно. Большая часть работы над реализацией openource, называемой бесконечным, уже была выполнена с jinfinote (https://github.com/sveith/jinfinote). Недавно Jinfinote портировали на python (https://github.com/phrearch/py-infinote) для обработки concurrency и централизованного документа. В настоящее время я использую оба проекта hwios (https://github.com/phrearch/hwios), который основывается на веб-сайтах и json-транспорте. Вы не хотите действительно хотеть использовать опрос для таких приложений. Также xmpp, кажется, слишком усложняет вещи.

Ответ 3

Совместное редактирование в режиме реального времени требует нескольких эффективных действий. Большинство других ответов здесь сосредоточены только на одном аспекте проблемы; а именно распределенное состояние (aka shared-mutable-state). Операционная трансформация (OT), неконфликтные реплицируемые типы данных (CRDT), дифференциальная синхронизация и другие связанные технологии - все это подходы к достижению распределенного состояния в режиме реального времени. В большинстве случаев основное внимание уделяется конечной последовательности, которая допускает временные расхождения каждого из участников, но гарантирует, что каждое из участников будет со временем сходиться при прекращении редактирования. В других ответах упоминалось о нескольких реализациях этих технологий.

Однако, как только вы разделите состояние mutable, вам понадобится несколько других функций, чтобы обеспечить разумный пользовательский интерфейс. Примеры этих дополнительных понятий включают в себя:

Идентификация: с кем вы сотрудничаете.
Присутствие. Кто сейчас "здесь" теперь редактирует.
Связь. Чат, аудио, видео и т.д., которые позволяют пользователям координировать действия.
Совместная Cueing: функции, которые дают указания относительно того, что делают другие участники и/или собираются сделать.

Общие курсоры и выбор являются примерами Collaborative Cueing (a.k.a Collaboration Awareness). Они помогают пользователям понять намерения и возможные действия других участников. Оригинальный плакат частично спрашивал о взаимодействии между совместно используемым изменчивым состоянием и совместной репликой. Это важно, потому что расположение курсора или выделение в документе обычно описывается через местоположения в документе. Проблема в том, что расположение курсора (например) зависит от контекста документа. Когда я говорю, что мой курсор находится в индексе 37, это означает, что в документе, на который я смотрю, находится символ 37. Документ, который у вас может быть прямо сейчас, может отличаться от моего, из-за ваших изменений или прав других пользователей, поэтому индекс 37 в вашем документе может быть неправильным.

Таким образом, механизм, который вы используете для распределения местоположений курсора, должен каким-то образом быть интегрирован в или, по крайней мере, знать о механизме системы, который обеспечивает управление concurrency через совместно используемое изменяемое состояние. Одна из проблем сегодня заключается в том, что, хотя есть много OT/CRDT, двунаправленных сообщений, чатов и других библиотек, они представляют собой изолированные решения, которые не интегрированы. Это затрудняет создание системы конечных пользователей, которая обеспечивает хороший пользовательский интерфейс и часто приводит к техническим проблемам, оставленным разработчиком для разработки.

В конечном счете, для реализации эффективной совместной системы редактирования в реальном времени вам необходимо рассмотреть все эти аспекты; и мы даже не обсуждали историю, авторизацию, разрешение конфликтов на уровне приложений и многие другие аспекты. Вы должны создавать или находить технологии, которые поддерживают каждую из этих концепций таким образом, который имеет смысл для вашего случая использования. Затем вы должны их интегрировать.

Хорошей новостью является то, что приложения, поддерживающие совместное редактирование, становятся все более популярными. Технологии, которые поддерживают их строительство, созревают, и новые становятся доступными каждый месяц. Firebase был одним из первых решений, которые пытались перевернуть многие из этих понятий в простой в использовании API. Новый пользователь Convergence (полное раскрытие, я являюсь основателем Convergence Labs), предоставляет API-интерфейс "все-в-одном", который поддерживает большинство из этих аспектов совместного редактирования и может значительно сократить время, стоимость и сложность создания приложений для совместной работы в режиме реального времени.

Ответ 4

После ответа на этот вопрос и более тщательного поиска я считаю, что лучшим автономным приложением для проверки будет Etherpad, который работает как браузер JS приложения и используя Node.js на стороне сервера. Эта технология известна как операционная трансформация.

Etherpad изначально была довольно тяжелым приложением, которое было куплено Google и включено в Google Wave, что не удалось. Код был выпущен как открытый источник, и технология была переписана в Javascript для Etherpad Lite, теперь переименована именно в "Etherpad". Некоторые из технологий Etherpad, вероятно, также были включены в Документы Google.

Начиная с Etherpad, для этой технологии были разные версии, в частности некоторые библиотеки Javascript, которые позволяют интегрировать их непосредственно в ваше веб-приложение:

Я поддерживаю пакет meteor-sharejs для добавления редакторов реального времени непосредственно в Meteor приложение, которое ИМХО является лучшим из обоих миров:)

Ответ 5

Как отметил Гинтаутас, это делается с помощью Операционной трансформации. Насколько я понимаю, основная часть исследований и разработок по этой функции была выполнена в рамках ныне существующего проекта Google Wave и известна как Wave Protocol. К счастью, Google Wave работает с открытым исходным кодом, поэтому вы можете получить хорошие образцы кода в http://code.google.com/p/wave-protocol/

Ответ 6

Команда Google Docs немного изучила пример того, как работает сотрудничество в режиме реального времени, но я не могу найти запись в блоге.

На странице wikipedia есть некоторые приличные вещи: http://en.wikipedia.org/wiki/Collaborative_real-time_editor

Ответ 7

Недавно я опубликовал репозиторий с рабочим примером того, что вы пытаетесь достичь:

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

Он основан на ShareDB (OT), работающем в качестве backend, и Quill расширенный текстовый редактор на интерфейсе.

В основном просто прокладывает все эти вещи с еще один код для рисования курсоров. Код должен быть достаточно простым для понимания и копирования на какое-либо конкретное решение.

Надеюсь, что это поможет в этом.