Операциональное преобразование (ОП) представляет собой технологию для поддержки целого ряда функциональных возможностей сотрудничества в передовых системах groupware . ОП было изначально придумано для поддержания согласованности и при совместном редактировании простых текстовых документов. Два десятилетия исследований расширили его возможности и области применения: групповая отмена, блокировка, разрешение конфликтов, уведомления и операции сжатия, развитие осознанности групповой работы, редактирование HTML/XML и древовидных документов, высокопроизводительные инструменты совместной работы в офисе, совместные приложения для общего доступа и инструменты совместного компьютерно-ориентированного медиа-дизайна. Недавно ОП была использована в качестве технологического ядра в Google Wave благодаря своим возможностям совместной работы, что вывело ОП на новый уровень веб-приложений.

История

Впервые концепцию Операционального Преобразования разработали С. Эллис, С. Гиббс в системе GROVE (GRoup Outtie Viewing Edit) в 1989 году. Несколько лет спустя были определены некоторые вопросы корректности и несколько независимых подходов решения этих вопросов, которые привели к следующему десятилетию продолжающихся усилий расширения и улучшения ОП сообществом посвященных этому исследователей. В 1998 году для развития связей и сотрудничества между исследователями СР и ОП была создана Группа Особого Интереса в Совместном Редактировании — Special Interest Group of Collaborative Editing 24 декабря 2012 года. . С тех пор SIGCE проводит ежегодные семинары по СР в ходе основных конференций CSCW ( ), таких как ACM CSCW, GROUP и ECSCW.

Архитектура системы

Системы совместной работы используют ОП, обычно повторяющую архитектуру хранения общих документов, чтобы обеспечить достаточное время отклика в средах с высокой задержкой, таких как Интернет. Общие документы копируются в локальное хранилище каждого сайта совместной работы, так что операции редактирования могут быть выполнены сразу на локальных сайтах, а затем переданы на удаленные сайты. Операции редактирования с удаленных сайтов, поступающие на локальный сайт, обычно уже преобразуются, а затем применяются. Преобразование гарантирует, что критерий согласованности, зависящий от приложения, будет достигнут на всех сайтах. Неблокируемое свойство ОП делает локальное время отклика нечувствительным к сетевым задержкам. В результате ОП очень хорошо подходят для реализации возможностей совместной работы, таких как групповое редактирование в контексте Web/Internet.

Основы

Основная идея ОП может быть проиллюстрирована на примере сценария редактирования простого текста следующим образом: Дан текстовый документ со строкой "abc", реплицированный на двух сайтах совместной работы; а также две одновременных операции:

1. O1 = Insert[0, "x"] (вставить символ "x" в позиции "0")
2. O2 = Delete[2, "c"] (удалить символ "c" в позиции "2")

генерируемые двумя пользователями на сайтах совместной работы 1 и 2, соответственно. Предположим, что две операции выполняются в следующем порядке: сначала O1 и затем O2 (на сайте 1). После выполнения O1 текст в документе становится "xabc". Для выполнения O2 после O1, O2 должна быть уже преобразована относительно O1 и предстать в следующем виде: O2'= Delete[3, "c"], где параметр позиции увеличен на единицу в связи со вставкой символа "x" операцией O1. Выполнение O2' на "xabc" должно удалить правильный символ "c" и текст этого документа становится "xab". Если же выполнять операцию O2 без преобразования, тогда будет неправильно удален символ "b" вместо "c". Основной идеей ОП является преобразование (или изменение) параметров операций редактирования в согласии с эффектами выполнения в предыдущих одновременных операциях так, чтобы преобразованная операция могла сработать корректно и не нарушать согласованность в документе.

Модели согласованности

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

CC модель

В для систем совместного редактирования потребовались два свойства согласованности:

• C ausality (Каузальность) или свойство старшинства по предшествованию: гарантирует, что порядок выполнения причинно-зависимых операций будет таким же, как их естественный причинно-следственный порядок, согласно процессу совместной работы. Каузальная связь между двумя операциями формально определяется соотношением Лампорта " ". Если две операции каузально независимы, они являются параллельными. Две параллельных операции могут выполняться в различном порядке на двух разных копиях документов.
• С onvergence (Сходимость): гарантирует, что реплицированные копии общего документа будут идентичными на всех сайтах (то есть, все генерируемые операции будут выполнены на всех сайтах).

Так как параллельные операции могут быть выполнены в разном порядке и операции редактирования обычно не коммутативны, копии документа на различных сайтах могут отличаться (быть несовместимыми). Первый алгоритм ОП был предложен в для достижения конвергенции в групповом текстовом редакторе; для хранения свойства старшинства использовался вектор состояния (или в классических распределенных вычислениях).

CCI модель

CCI модель была предложена в качестве общего фреймворка для управления согласованностью в системах совместного редактирования . Внутри CCI модели, сгруппированы вместе три свойства согласованности:

• С ausality Preservation (Сохранность Каузальности): то же самое, что и свойство старшинства по предшествованию в CC модели.
• С onvergence : то же самое, что свойство конвергентности в CC модели.
• I ntention Preservation (Сохранность Намерения): гарантирует, что эффект выполнения операции в любом состоянии документа, будет таким же, как и намеревалось при выполнении операции. Намерение операции O определяется как эффект выполнения, который может быть достигнут путём применения O на состоянии документа, из которого О была сгенерирована.

CCI модель расширяет CC модель новым критерием: Сохранность Намерения. Существенная разница между конвергенцией и сохранностью намерения состоит в том, что первое всегда может быть достигнуто путём сериализации протокола, однако последнее не может быть достигнуто за счёт сериализации какого-либо протокола, если операции всегда будут выполняться в их первоначальных формах. Обеспечение свойства сохранности несериализуемого намерения являлось главной технической задачей. Обнаружилось, что ОП очень хорошо подходит для обеспечения конвергенции и сохранности намерения в системах совместного редактирования.

CCI модель не зависима от типов документов или моделей данных, видов операций, или вспомогательных технологий (ОП, мульти-версионность, сериализация, undo/redo). Она не предназначена для проверки правильности методов (например ОП), которые разрабатывались для конкретных данных и операционных моделей и для конкретных приложений. В понятие сохранности намерения определялось и уточнялось на трёх уровнях: во-первых, оно было определено как исходное требование согласованности в системах совместного редактирования; во-вторых, оно была определено как операция, основанная на контексте условий пред- и пост-преобразования для исходных функций ОП; в-третьих, оно было определено как специфичная операция проверки критериев, которыми следует руководствоваться при разработке функций OП для двух простейших операций: строковые функции вставки и удаления в простых текстовых редакторах для совместной работы.

CSM модель

Условие сохранности намерения не было формально определено в CCI модели для целей формальных доказательств. В SDT и LBT подходах сделаны попытки формализовать альтернативные условия, которые могут быть использованы для доказательств. Модель согласованности, предложенная в этих двух подходах, состоит из следующих формальных условий:

• C ausality (Каузальность): определяет то же самое, что и в CC модели
• S ingle-operation effects (Следствия выполнения одной операции): следствие от выполнения любой операции в любом состоянии выполнения достигает того же эффекта, что и в его исходном состоянии
• М ulti-operation effects (Следствия выполнения нескольких операций): зависимость следствий любых двух операций поддерживаются и после того, как они оба будут выполнены в любых состояниях

CA модель

Приведенная выше CSM модель требует, чтобы в системе был определен общий порядок всех объектов. Следовательно, спецификация сводится к новым объектам, представляемым операциями вставки. Однако, спецификация общего порядка влечет за собой применение зависимых от приложения стратегий, таких как при разрыве связей для вставки (т.е., когда новые объекты вставляются двумя текущими операций в одну и ту же позицию). Таким образом, общий порядок становится зависимым от приложения. Более того, в функциях преобразования и процедуре управления алгоритма общий порядок должен сохраняться, что приводит к увеличению сложности времени/пространства алгоритма.

В качестве альтернативы, CA модель основывается на Admissibilty Theory (Теории допустимости). CA модель включает в себя два аспекта:

• С ausality (Каузальность): определяет то же самое, что и в CC модели
• А dmissibility (Допустимость): Вызов каждой операции является допустимым в своем состоянии исполнения, т.е. каждый вызов не должен нарушать каких-либо связанных следствий (построения объектов), которые были созданы более ранними вызовами.

Эти два условия подразумевают собой конвергенцию. Все кооперирущие между собой сайты сходятся в одном и том же состоянии, в котором имеется один и тот же набор объектов, что находятся в одном и том же порядке. Более того, порядок фактически определяет следствия операций, которые они генерируют. Поскольку два условия также вводят дополнительные ограничения на порядок объектов, они фактически имеют больший приоритет, чем конвергенция. CA модель и подходы к его дизайну/обоснованиям были разработаны в 2005 году в статье . Это уже не требовало того, чтобы общий порядок объектов был определен в модели согласованности и поддерживался алгоритмом, что, соответственно, приводет к уменьшению сложности времени/пространства алгоритма.

Структура системы ОП

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

Алгоритм управления преобразованием связан с определением:

1. Какая операция должна быть преобразована перед каузально-произошедшей новой операцией
2. Порядка преобразований

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

Другой альтернативный подход предложен в .В этом подходе, алгоритм ОП является корректным, если он удовлетворяет двум формализованным критериям корректности:

1. Сохранности каузальности
2. Сохранности допустимости

До тех пор, пока система удовлетворяет этим двум критериям, после того, как все операции будут выполнены на всех сайтах, копии данных становятся конвергентными (с дополнительными ограничениями). Нет необходимости принудительно для достижения конвергентности вводить общий порядок выполнения. Их подход в основном заключается в том, чтобы сначала идентифицировать и подтвердить достаточные условия для нескольких функций преобразования, а затем разрабатывать процедуры контроля для обеспечения этих достаточных условий. Таким образом, процедуры управления и функции преобразования синергетически (совместно) достигают корректности, т.е. сохранности каузальности и допустимости. В этом подходе нет необходимости соблюдения критериев свойств преобразований, таких как, например, TP2, поскольку это не требует работы (включения) функций преобразования во всех возможных случаях.

Данные ОП и операционные модели

В каждой системе ОП существуют две основополагающие модели: модель данных, которая определяет, как операции адресуются к объектам данных в документе и операционная модель, которая определяет набор операций, которые могут быть непосредственно преобразовываться функциями ОП. Различные системы ОП могут иметь разные данные и операционные модели. Например, модель данных первой системы ОП представляет собой единое линейное адресное пространство; а её операционная модель состоит из двух примитивных операций: посимвольная вставка и удаление. Базовая операционная модель была расширена третьей примитивной операцией обновления, для поддержки совместной обработки документов Word и редактирования 3D моделей . Базовая модель данных ОП была расширена в иерархию из нескольких областей с линейной адресацией , которая стала способна моделировать широкий спектр различных документов. В процессе адаптации данных, часто требуется спроецировать конкретно зависимые от применения модели данных на ОП-совместимые модели данных .

Для поддержки операций в системе ОП на уровне приложений, существуют два подхода:

1. Подход с моделью исходных операций: который отталкивается в разработке функций преобразования от трёх примитивных операций: вставки, удаления и обновления . Такой подход нуждается в работе по привязке процесса приведения применяемых операций к этим примитивным операциям. В этом подходе, операционная модель ОП является исходной, при этом одни и те же функции преобразования могут быть использованы для разных приложений.
2. Подход с операционной моделью, зависящей от конкретного приложения: который отталкивается в разработке функций преобразования от каждой пары операций приложения . В приложении с m различных операций, потребуется m x m функций преобразования, необходимых для поддержки этого приложения. В рамках этого подхода, функции преобразования являются зависимыми от конкретного приложения и не могут быть повторно использованы в других приложениях.

Функции ОП

Разнообразные функции ОП были разработаны для систем ОП с разными возможностями и использования в разных приложениях. Функции ОП, используемые в разных системах OП, могут называться по-разному, но все они могут быть классифицироваться по двум категориям:

• одна — включающее преобразование Inclusion Transformation (или прямое преобразование): IT (Oa, Ob) или ${\displaystyle T(op_{1},op_{2})}$ , которая преобразует операцию Oa перед другой операцией Ob таким образом, что учитывается (включается) фактическое влияние Ob; и
• другая — исключающее преобразование Exclusion Transformation (или обратное преобразование): ET (Oa, Ob) или ${\displaystyle T^{-1}(op_{1},op_{2})}$ , которая преобразует операцию Oa перед другой операцией Ob таким образом, что влияние Ob фактически исключается (не учитывается).

Например, рассмотрим строковую операцию ins(p, c, sid), где p — позиция вставки, с — вставляемый символ и sid — идентификатор на сайте, где сгенерирована операция. Мы можем написать следующую функцию преобразования:

${\displaystyle T}$(ins(${\displaystyle p_{1},c_{1},sid_{1}}$),ins(${\displaystyle p_{2},c_{2},sid_{2}}$)) :-
  if (${\displaystyle p_{1}<p_{2}}$) return ins(${\displaystyle p_{1},c_{1},sid_{1}}$)
  else if (${\displaystyle p_{1}=p_{2}}$ and ${\displaystyle sid_{1}<sid_{2}}$) return ins(${\displaystyle p_{1},c_{1},sid_{1}}$)
  else return ins(${\displaystyle p_{1}+1,c_{1},sid_{1}}$)

${\displaystyle T^{-1}}$(ins(${\displaystyle p_{1},c_{1},sid_{1}}$),ins(${\displaystyle p_{2},c_{2},sid_{2}}$)) :-
  if (${\displaystyle p_{1}<p_{2}}$) return ins(${\displaystyle p_{1},c_{1},sid_{1}}$)
  else if (${\displaystyle p_{1}=p_{2}}$ and ${\displaystyle sid_{1}<sid_{2}}$) return ins(${\displaystyle p_{1},c_{1},sid_{1}}$)
  else return ins(${\displaystyle p_{1}-1,c_{1},sid_{1}}$)

Некоторые системы ОП используют обе функции: IT и ET, а некоторые используют только IT функцию. Сложность разработки функций ОП определяется различными факторами:

• функциональностью системы ОП: поддерживает ли система ОП действия do (обеспечивает ли согласованность), undo, блокировок , информирования, разделения приложения другими пользователями и т.д.;
• корректностью характеристик ответных реакций в системе ОП: какие свойства преобразования вводятся (CP1/TP1, CP2/TP2, IP2, IP3, RP), используется ли ET;
• операционной моделью системы ОП: является ли модель оперирования исходной (например, примитивные вставки, удаления, обновления), или зависимой от конкретного приложения (все операции целевого приложения); и
• моделью данных системы OП: будут ли данные в каждой операции посимвольными (индивидуальными объектами), строковыми (последовательностями объектов), иерархическими, или иметь другие структуры.

Свойства преобразований

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

Свойства конвергенции

Следующие два свойства имеют отношение к достижению конвергенции.

• CP1/TP1: Для каждой пары одновременных операций ${\displaystyle op_{1}}$ и ${\displaystyle op_{2}}$ определённых для одного и того же состояния, функция преобразования ${\displaystyle T}$ удовлетворяет свойству CP1/TP1 тогда и только тогда, когда: ${\displaystyle op_{1}\circ T(op_{2},op_{1})\equiv op_{2}\circ T(op_{1},op_{2})}$ , где ${\displaystyle op_{i}\circ op_{j}}$ означает последовательность операций, содержащей ${\displaystyle op_{i}}$ следующей за ${\displaystyle op_{j}}$ и где ${\displaystyle \equiv }$ означает эквивалентность двух последовательностей операций. Предварительные условия CP1/TP1: CP1/TP1 требуется только в том случае, если система ОП разрешает любым двух операциям выполняться в разном порядке.
• CP2/TP2: Для каждых трёх одновременных операций ${\displaystyle op_{1},op_{2}}$ и ${\displaystyle op_{3}}$ определённых для одного и того же состояния документа, функция преобразования ${\displaystyle T}$ удовлетворяет свойству CP2/TP2 тогда и только тогда, когда: ${\displaystyle T(op_{3},op_{1}\circ T(op_{2},op_{1}))=T(op_{3},op_{2}\circ T(op_{1},op_{2}))}$ . CP2/TP2 предусматривает тождество между двумя операциями, преобразованными относительно двух эквивалентных последовательностей операций: преобразование ${\displaystyle op_{3}}$ перед последовательностью операции ${\displaystyle op_{2}}$ следующей за ${\displaystyle T(op_{1},op_{2})}$ должно давать такую же операцию, как и преобразование ${\displaystyle op_{3}}$ перед последовательностью, сформированную из ${\displaystyle op_{1}}$ и ${\displaystyle T(op_{2},op_{1})}$ . Предварительные условия CP2/TP2: CP2/TP2 требуется только в том случае, если система ОП позволяет двум операциям ${\displaystyle op_{1}}$ и ${\displaystyle op_{2}}$ быть IT-преобразоваными в два разных состояниях документа (или контекста).

Свойства инверсии

Следующие три свойства имеют отношение к достижению требуемого эффекта групповой отмены. Этими свойствами являются:

• IP1: При любом состоянии документа ${\displaystyle S}$ и последовательности ${\displaystyle op\circ {\overline {op}}}$ , мы имеем тождество ${\displaystyle S\circ op\circ {\overline {op}}=S}$ , которое означает, что последовательность ${\displaystyle op\circ {\overline {op}}}$ эквивалентна единственной идентичности операции I в том, что касается воздействия на состояние документа. Это свойство требуется в системах ОП для обеспечения корректности эффекта групповой отмены, но не связано с функциями IT.
• IP2: Свойство IP2 выражает то, что последовательность ${\displaystyle op\circ {\overline {op}}}$ не оказывает никакого влияния на преобразование других операций. Функции преобразования удовлетворяют свойству IP2 тогда и только тогда, когда выполняется тождество ${\displaystyle T(op_{x},op\circ {\overline {op}})=op_{x}}$ , которое означает, что результат преобразования ${\displaystyle op_{x}}$ перед последовательностью ${\displaystyle op\circ {\overline {op}}}$ эквивалентно результату преобразования ${\displaystyle op_{x}}$ перед определяющей операцией I. Предварительные условия IP2: IP2 требуется только в случае, если система ОП позволяет операциям ${\displaystyle op_{x}}$ быть преобразованными перед парой операций действия и отмены ${\displaystyle op\circ {\overline {op}}}$ , один за другим.
• IP3: Если заданы две одновременных операции ${\displaystyle op_{1}}$ и ${\displaystyle op_{2}}$ , определяемые на одном и том же состоянии документа (или контекста), тогда ${\displaystyle {\overline {op_{1}}}'=T({\overline {op_{1}}},T(op_{2},op1))}$ и ${\displaystyle {\overline {op_{1}'}}={\overline {T(op_{1},op_{2})}}}$ . Функции преобразования удовлетворяют свойству IP3 тогда и только тогда, когда выполняется тождество ${\displaystyle {\overline {op_{1}}}'={\overline {op_{1}'}}}$ , которое означает, что преобразованная инверсия операции ${\displaystyle {\overline {op_{1}}}'}$ эквивалентна инверсии преобразованной операции ${\displaystyle {\overline {op_{1}'}}}$ . Предварительные условия IP3: IP3 требуется только в случае, если система ОП позволяет операции инверсии ${\displaystyle {\overline {op_{1}}}}$ быть преобразованной перед операцией ${\displaystyle op_{2}}$ , которая является одновременной и определяется на том же состоянии документа (или контекстно-эквивалентно) что и ${\displaystyle op_{1}}$ .

Алгоритмы управления (интеграции) ОП

Разнообразные алгоритмы управления ОП были разработаны для систем ОП с различными возможностями и для разных приложений. Сложность разработки алгоритма управления ОП определяется несколькими факторами. Ключевым различающим фактором того или иного алгоритма является способность поддерживать управление параллельным выполнением (do), и/или групповой отменой (undo) . Кроме того, разные схемы алгоритмов управления ОП допускают различные компромиссы в:

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

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

В нижеследующей таблице приводится обзор некоторых существующих алгоритмов управления/интеграции ОП

Алгоритмы (системы) управления/интеграции ОП	Требуемые типы функций преобразования	Поддержка на базе ОП действий (do)	Поддержка на базе ОП отмены (undo)	Преобразование свойств, поддерживаемых алгоритмом управления	Преобразование свойств, поддерживаемых функциями преобразования	Преобразование порядка и ограничения распространенности	Представление меток времени
dOPT (GROVE)	T (IT)	Да	Нет	Отсутствует	CP1/TP1, CP2/TP2	Каузальный порядок	Вектор состояния
selective-undo (DistEdit)	Transpose (IT и ET)	Нет	Выборочная отмена	Не доступно	CP1/TP1, CP2/TP2, RP, IP1, IP2, IP3	Каузальный порядок	??
adOPTed (JOINT EMACS)	LTransformation (IT)	Да	Хронологическая отмена	IP2, IP3	CP1/TP1, CP2/TP2, IP1	Каузальный порядок	Вектор состояния
Jupiter	xform (IT)	Да	Нет	CP2/TP2	CP1/TP1	Каузальный порядок + центральный сервер преобразования	Скалярные
ОП Google Wave	преобразование и композиция (IT)	Да	??	CP2/TP2	CP1/TP1	Каузальный порядок + центральный сервер преобразования + протокол распространения stop'n'wait	Скалярные
GOT (REDUCE)	IT и ET	Да	Нет	CP1/TP1, CP2/TP2	Отсутствует	Каузальный порядок + дискретный общий порядок	Вектор состояния
GOTO (REDUCE, CoWord, CoPPT, CoMaya)	IT и ET	Да	Нет	Отсутствует	CP1/TP1, CP2/TP2	Каузальный порядок	Вектор состояния
AnyUndo (REDUCE, CoWord, CoPPT, CoMaya)	IT и ET	Нет	Отмена любой операции	IP2, IP3, RP	IP1, CP1/TP1, CP2/TP2	Каузальный порядок	Вектор состояния
SCOP (NICE)	IT	Да	Нет	CP2/TP2	CP1/TP1	Каузальный порядок + центральный сервер преобразования	Скалярное
COT (REDUCE, CoWord, CoPPT, CoMaya)	IT	Да	Отмена любой операции	CP2/TP2, IP2, IP3	CP1/TP1, IP1	Каузальный порядок + дискретный общий порядок	Вектор контекста
TIBOT	IT	Да	Нет	CP2/TP2	CP1/TP1	Каузальный порядок	Скалярные
SOCT4	Прямое преобразование (IT)	Да	Нет	CP2/TP2	CP1/TP1	Каузальный порядок + непрерывный общий порядок	Скалярное
SOCT2	Прямое преобразование (IT) и обратное преобразование (ET)	Да	Нет	Отсутствует	CP1/TP1, CP2/TP2, RP	Каузальный порядок	Вектор состояния
MOT2	Прямое преобразование (IT)	Да	Нет	??	CP1/TP1	??	??

Непрерывный общий порядок является строгим , который можно определить по отсутствию элементов, т.е. 1,2,3,4, ... представляет собой непрерывный общий порядок, а 1,2,3,5, ... не является непрерывным общим порядком.

Алгоритмы на основе преобразований, предложенные в базируются на альтернативных моделях согласованности CSM и CA , описанных выше. Их подходы отличаются от тех, что перечислены в таблице. Для сохранности каузальности в них используется вектор временных меток. Другими условиями корректности является сохранность зависимости одно- / мульти- следствий операций или сохранность допустимости . Эти условия обеспечиваются совместной работой процедуры управления и функций преобразования. Рассматривать TP1/TP2 в их работе нет необходимости. Потому они не перечислены в таблице выше.

Существуют и некоторые другие алгоритмы управления оптимистического согласования, которые находят альтернативные методы для разработки алгоритмов преобразования, но не вписываются в приводимую выше таксономию и описания характеристик. Они перечислены ниже:

• Маркировка и возврат

Программное обеспечение ОП

• Совместные редакторы простого текста (одномерные документы)
  • (коммерческое)
  • (бесплатное, с открытым исходным кодом)
  • Gobby (бесплатное, с открытым исходным кодом)
  • (бесплатное для некоммерческого использования, с открытым исходным кодом)
  • ICT представляет собой исследовательский прототип, который подходит для любой команды редактирования любого (текстового) редактора.Его управление согласованностью основывается на сочетании различий и операционального преобразования.
• Совместные высокопроизводительные приложения (двумерные документы)
  • представляет собой текстовый процессор, основанный на Microsoft Word, для совместной работы в режиме реального времени
  • представляет собой редактор презентаций, основанный на Microsoft PowerPoint, для совместной работы в режиме реального времени
• Совместные инструменты для компьютерного медиа-дизайна (трехмерные документы)
  • от 22 сентября 2009 на Wayback Machine представляет собой инструмент для 3D дизайна, основанный на Autodesk Maya, для совместной работы в режиме реального времени
• Веб-приложения*
  • Google Wave использует ОП как часть Google Wave Federation Protocol . Aлгоритм ОП в Google Wave базируется на коде Jupiter
  • от 1 ноября 2012 на Wayback Machine является бесплатным веб-ориентированным редактором для совместной работы несколькими группами участников. Доступна коммерческая версия для работы в интрасетях
• Системы управления версиями
  • So6 является бесплатной системой управления версиями с открытым исходным кодом, интегрированной в платформу .

Примечания

Ссылки

• 24 декабря 2012 года.
• от 15 июня 2009 на Wayback Machine
• от 28 сентября 2011 на Wayback Machine

Дополнительные ресурсы онлайн

• от 13 января 2017 на Wayback Machine
• от 19 июля 2018 на Wayback Machine