Совместное редактирование в реальном времени-как это работает?
Я пишу приложение, в котором я хотел бы иметь возможности совместного редактирования документов в режиме реального времени (очень похоже на редактирование стиля документов Google).
Я знаю, как отслеживать положение курсора, это просто. Просто опросите сервер когда-либо половину секунды или секунду с текущим идентификатором пользователя, именем файла, номером строки и номером строки, которые могут быть сохранены в базе данных, а возвращаемое значение этого запроса опроса-это позиция другого пользователя указатели.
то, что я не знаю, как сделать, это обновить документ таким образом, чтобы он не отбрасывал курсор и не заставлял полную перезагрузку, поскольку это было бы слишком медленно для моих целей.
Это действительно должно работать только в Google Chrome, предпочтительно Firefox. Мне не нужно поддерживать какой-либо другой браузер.
7 ответов:
алгоритм, используемый за кулисами для объединения совместных правок из нескольких одноранговых узлов, называется операционные преобразования. Однако это не тривиально реализовать.
см. также этот вопрос полезные ссылки.
вам не нужно xmpp или волна для этого обязательно. Большая часть работы над реализацией с открытым исходным кодом под названием 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.
совместное редактирование в реальном времени требует нескольких вещей, чтобы быть эффективным. Большинство других ответов здесь сосредоточены только на одном аспекте проблемы; а именно распределенное состояние (ака shared-mutable-state). Операционное преобразование (OT), бесконфликтные реплицированные типы данных (CRDT), дифференциальная синхронизация и другие связанные технологии-все это подходы к достижению распределенного состояния, близкого к реальному времени. Большинство фокусируется на конечной согласованности, которая позволяет временные расхождения каждого из участники заявляют, но гарантируют, что каждое состояние участников в конечном итоге сойдется при остановке редактирования. В других ответах упоминалось несколько реализаций этих технологий.
однако, как только вы поделились изменяемым состоянием, вам нужно несколько других функций, чтобы обеспечить разумный пользовательский интерфейс. Примеры этих дополнительных понятий включают:
- личность: С кем вы сотрудничаете являются.
- присутствие: кто в настоящее время "здесь" редактирование с вами сейчас.
- сообщении: чат, аудио, видео и т. д., что позволяет пользователям координировать действия
- совместные Cueing: функции, которые дают указания относительно того, что делают и/или собираются делать другие участники.
общие курсоры и выборки являются примерами совместного использования Cueing (a.k.A Collaboration Awareness). Они помогают пользователи понимают намерения и вероятные последующие действия других участников. Оригинальный плакат частично спрашивал о взаимодействии между разделяемым изменяемым состоянием и совместным созданием сигналов. Это важно, потому что расположение курсора или выделения в документе обычно описывается через расположения в документе. Проблема заключается в том, что расположение курсора (например) зависит от контекста документа. Когда я говорю, что мой курсор находится в индексе 37, это означает символ 37 в документе, на который я смотрю. Документ, который вы можете иметь прямо сейчас, может отличаться от моего из-за ваших правок или правок других пользователей, и поэтому индекс 37 в вашем документе может быть неверным.
таким образом, механизм, который вы используете для распределения местоположений курсора, должен быть каким-то образом интегрирован или, по крайней мере, осведомлен о механизме системы, который обеспечивает контроль параллелизма над общим изменяемым состоянием. Одна из проблем сегодня заключается в том, что в то время как есть много OT / CRDT, двунаправленные сообщения, чат и другие библиотеки-это изолированные решения, которые не интегрированы. Это затрудняет создание системы конечного пользователя, которая обеспечивает хороший пользовательский интерфейс, и часто приводит к техническим проблемам, оставленным разработчику для выяснения.
в конечном счете, чтобы реализовать эффективную систему совместного редактирования в реальном времени, вам нужно рассмотреть все эти аспекты; и мы даже не обсуждали историю, авторизацию, конфликт на уровне приложений разрешение, и много других фасеток. Вы должны построить или найти технологии, которые поддерживают каждую из этих концепций таким образом, чтобы это имело смысл для вашего варианта использования. Тогда вы должны интегрировать их.
хорошей новостью является то, что приложения, поддерживающие совместное редактирование, становятся все более популярными. Технологии, которые поддерживают их строительство, созревают, и новые становятся доступными каждый месяц. военнослужащих одним из первых решений, которые пытались обернуть во многих из этих концепции в простой в использовании API. Новичок совпадение (полное раскрытие, я основатель Convergence Labs), предоставляет универсальный API, который поддерживает большинство этих аспектов совместного редактирования и может значительно сократить время, стоимость и сложность создания приложений для совместного редактирования в реальном времени.
после того, как вы столкнетесь с этим вопросом и сделаете более тщательный поиск, я думаю, что лучшим автономным приложением для проверки будет Etherpad, который работает как приложение браузера JS и использует узел.JS на стороне сервера. Технология, стоящая за этим, известна как операционные преобразования.
Etherpad изначально был довольно тяжеловесным приложением, которое было куплено Google и включено в Google Wave, что не удалось. Код был выпущен как открытый источник и технология были переписаны на Javascript для Etherpad Lite, теперь переименованы просто "Etherpad". Некоторые из технологий Etherpad, вероятно, также были включены в Google Docs.
начиная с Etherpad, существуют различные версии этой технологии, в частности некоторые библиотеки Javascript, которые позволяют интегрировать это непосредственно в ваше веб-приложение:
Я сопровождающий meteor-sharejs пакет для добавления редакторов реального времени непосредственно в Метеор приложение, которое IMHO является лучшим из обоих миров:)
Как отметил Гинтаутас, это делается путем оперативного преобразования. Насколько я понимаю, основная часть исследований и разработок по этой функции была выполнена в рамках ныне несуществующего проекта Google Wave и известна как протокол Wave. К счастью, Google Wave является открытым исходным кодом, так что вы можете получить некоторые хорошие примеры кода на http://code.google.com/p/wave-protocol/
команда Google Docs провела небольшое тематическое исследование о том, как работает сотрудничество в реальном времени, но я не могу найти запись в блоге.
есть некоторые приличные вещи на странице Википедии, хотя: http://en.wikipedia.org/wiki/Collaborative_real-time_editor
недавно я опубликовал репозиторий с рабочим примером того, что вы пытаетесь достичь:
https://quill-sharedb-cursors.herokuapp.com
Он основан от ShareDB (OT) работа в качестве бэкэнда и Quill rich text editor на интерфейсе.
в основном просто провода все эти вещи с еще немного кода для рисования курсоров. Код должен быть достаточно простым для понимания и скопируйте в любое конкретное решение.
надеюсь, что это помогает с работой.