Fugue论文在Jupiter-OT问题上的揭秘

本文是对“The Art of the Fugue: Minimizing Interleaving in Collaborative Text Editing”（简称Fugue论文）一系列评论文章的第2篇。 评论来自于Prof. Sun在Medium的文章（已获授权翻译）:https://medium.com/codox/a-critical-examination-of-the-fugue-paper-in-relation-to-ot-157f6ccaed95

1. 引言

我们先来考察一下Fugue论文（A.1.3 节，第19页）中试图阐述Jupiter-OT中的“交错”（interleaving）问题的原文：

Jupiter论文[1]没有明确规定并发插入的转换函数，它只是口头描述为：“如果双方（即服务器和客户端）都试图在同一位置插入，我们武断地选择将服务器的文本放在前面。”我们证明，即使是这种非正式的定义，也意味着该算法会表现出正向交错（forward interleaving）。

从一个空文档开始，假设客户端 A 生成了 ins(1, a)随后是ins(2, b)，而客户端B并发地生成了ins(1, x)。考虑服务器上的执行过程：

1. 假设客户端A的ins(1, a)是第一个到达服务器的操作，因此服务器直接执行，文档结果为 a。

2. 接着，客户端B的ins(1, x)到达服务器。由于ins(1, a)是由服务器并发地应用的，我们在同一位置有了两个并发插入。根据此类插入的规则，服务器的字符（即 a）被放在前面，客户端的x被放在后面。这意味着B的操作被转换为ins(2, x)，服务器的文档现在为ax。

3. 最后，客户端 A 的 ins(2, b)到达服务器。与此并发的是，服务器现已执行了ins(2, x)，这是B 操作的转换形式。我们再次在同一位置（在本例中为索引2）有了两个并发插入。根据上述规则，我们把服务器的字符x放在前面，客户端的字符b放在后面。这意味着A的操作被转换为ins(3, b)，服务器的文档现在为axb，表现出正向交错

Fugue论文，特别是在上文引用的文字中，针对广义的协同编辑技术 (OT) 和具体的Jupiter-OT算法提出了多个问题。为便于集中分析，这些问题已被划分为三个不同的部分。

2. Jupiter-OT能够支持字符串级协同编辑

我想提及以下引用的陈述：“如果双方（即服务器和客户端）都试图在同一位置插入，我们武断地选择将服务器的文本放在前面。”该陈述是从Jupiter-OT论文中的完整段落（第119页的第1段）中断章取义的，完整段落内容如下：

TextEdits 的 Replace（替换）操作会删除一个文本区域，然后插入一个字符串来替换它。对于 Replace 对 Replace 的转换，其产生的最终状态需要满足以下条件：(a) 移除了任一 Replace 所请求删除的所有文本；(b) 插入了各自请求插入的文本，并按照删除区域的起始点进行排序。如果双方都试图在同一位置插入，我们武断地选择了将服务器的文本放在前面。

很明显，Jupiter-OT支持一种称为“替换”（replace）的字符串级编辑操作，该操作涉及一个字符串级的删除，紧随其后是一个字符串级的插入。

2.1 基于OT字符串级协同编辑的独特特性

在 OT（协同编辑技术）领域，字符串级协同编辑不仅比字符级协同编辑更高效，而且还具备鲜明的特性。其中一个特性是它能够在插入过程中保持连续文本区域的完整性，确保区域内的所有文本作为一个内聚的单元插入，而不会与并发插入的内容交织在一起。

此外，需要强调的是，捕获连续文本区域是支持字符串级协同编辑的一个内在方面。这些区域可以通过多种操作产生，例如连续输入、复制粘贴任意大小的文本片段，或者在离线协同编辑中任意插入和删除操作所导致的文本连续积累。正是由于在常见的编辑操作中会自然地创建连续字符串，才凸显了文本交错是不可取的事实，并证明了在协同编辑中避免交错的努力是合理的。

遗憾的是，这种字符串级与字符级协同编辑之间的重要区别，在许多只关注字符级文本编辑的协同编辑论文中经常被忽视或忽略。这种疏忽在 Fugue 论文中表现得很明显：客户端 A 连续插入两个字符“a”和“b”，被表示成了两个单独的字符级操作：insert(1,a)和insert(2,b)，而不是一个字符串级的insert(1,ab)。后者本应可以在Jupiter-OT或其他支持字符串级协同编辑的OT解决方案中实现。

2.2 字符串级协同编辑消除了交错

通过字符串级操作insert(1,ab)来捕获字符“a”和“b”的连续插入，可以明确得出结论：Jupiter-OT服务器上的最终执行结果应该完全消除任何交错的可能性，如下所示（所有其他条件与 Fugue 论文中描述的相同）：

从一个空文档开始，假设客户端 A 启动了两个字符“a”和“b”的连续插入，产生了操作 ins(1, ab)；而客户端 B 并发地插入一个字符“x”，产生了操作 ins(1, x)。现在考察服务器上的执行过程：

1. 假设客户端 A 的insert(1,ab)是第一个到达服务器的操作，服务器直接应用它，文档结果为 “ab”。

2. 接着，客户端 B 的 ins(1, x) 到达服务器。由于服务器已应用了insert(1,ab)，我们在同一位置有了两个并发插入。根据此类插入的规则，服务器的文本 “ab” 被放在前面，客户端的 “x” 被放在后面。这意味着 B 的操作被转换为 ins(3, x)，服务器的文档现在为 “abx”——一个非交错的结果。 如果打破僵局的规则被颠倒，即当双方都试图在同一位置插入时，服务器的文本被放在客户端文本之后，那么结果将是 “xab”，它依然是非交错的。

总而言之，Jupiter-OT和其他支持字符串级协同编辑的OT解决方案，都采用字符串级操作来处理连续文本区域的插入。这些解决方案保证：在同一位置并发插入的字符串，会在合并后的文档状态中按顺序放置，保持一致的顺序，而不会将来自不同字符串的字符相互混杂。

3. Jupiter-OT被限制为仅支持字符级协同编辑

如果Jupiter-OT被限制为仅支持字符级协同编辑，结果会是怎样？直接的答案是，一致且非交错的结果仍然可以实现。

3.1 将Jupiter-OT与字符级转换函数相结合

让我们来探讨将Jupiter-OT控制算法与OTFAQ[3]中Q&A 2.15 节（如图1所示）所描述的字符级转换函数相结合的情况。

​

图1

这种组合完全合适，并且不会产生任何问题。Jupiter-OT控制算法，以及其他著名的OT控制算法，如adOPTed、GOT、GOTO、COT、POT等，都被设计为通用（generic）的。正如OTFAQ中题为《如何通过结合现有控制算法和转换函数来创建正确的 OT 系统？》的Q&A 3.19 节所阐述的那样，这种设计允许其与不同的转换函数进行灵活集成。

3.2 避免字符交错的字符级转换

在图1中，当两个并发操作在同一位置插入时，插入打破僵局的规则是：用户ID较小的操作将被右移（right-shifted）。

在与Fugue论文中描述的相似条件下（假设 A > B），Jupiter服务器上将展开以下事件序列：

1. 假设 ins(1, a, A) 是第一个到达服务器的操作，它被直接应用，文档状态结果为 “a”。

2. 接着，ins(1, x, B) 到达服务器。由于 ins(1, x, B) 与 ins(1, a, A) 是并发且上下文等效的，服务器应用转换T(ins(1, x, B), ins(1, a, A))。由于条件1 = 1且 A > B（即B的ID较小），其结果是ins(2, x, B)。执行ins(2, x, B)得到文档状态 “ax”。

3. 最后，ins(2, b, A)到达服务器。此操作与ins(2, X, B)是并发且上下文等效的。服务器应用转T(ins(2, b, A), ins(2, X, B))。由于条件2 = 2且A > B（即B的ID较小，A的ID较大，因此A的操作没有被右移），其结果是ins(2, b, A)。执行ins(2, b, A)得到文档状态 “abx”（非交错）。

如果打破僵局的规则被颠倒（即A < B），将获得另一个非交错的结果：“xab”。正如这个简单示例所示，Jupiter-OT即使在与纯字符级转换函数一起使用时，也能够持续地生成非交错的结果。

3.3 OT解决方案的共同特征

敏锐的读者会发现，上文在Jupiter-OT背景下展示的字符级协同编辑示例，与我之前帖子中使用 adOPTed控制算法对客户端B的修正图示（图2和图4）之间存在惊人的相似性。很明显，adOPTed和Jupiter-OT两种控制算法都持续地产生非交错的结果。这种相似性并非巧合，而是许多通用OT控制算法所共有的特性。

总而言之，无论Jupiter-OT是与字符串级还是字符级转换函数集成，它都能够持续地提供非交错的结果。

4. 协同编辑的现状与未来

在过去三十年中，协同编辑经历了重大的发展，在理论和实践上都推动了协同编辑的前沿并重塑了其格局。

4.1 转向新的、真正的挑战

特别值得注意的是，该领域早已从早期的纯文本字符级协同编辑演进到字符串级协同编辑和富文本协作广泛采用的时代。这些进步已融入现实世界的协同编辑产品中，使用户能够协作编辑不仅是纯文本，还包括复杂的数据结构，如带样式文本、表格、项目列表和图形。

随着该领域不断发展以满足对更复杂功能和应用日益增长的需求，新的、真正的技术挑战也持续涌现，这要求我们恰当地引导我们的努力，去应对这些挑战并推动该领域向前发展。

4.2 道路选择：向前还是向后？

鉴于当前的协同编辑技术现状和我们面临的新挑战，令人困惑的是，竟然出现了以纯文本字符级协同编辑为中心的倒退式复苏工作。这些工作常常深入研究一些看似人为设计的课题，例如Fugue 论文中探讨的“反向交错”（backward interleaving）。

“反向交错”的概念探讨了在逆序输入下发生字符级交错的可能性。例如，考察一个字符串“abc”是逆序创建的场景：先输入“c”，其次是“b”，最后是“a”。现在，假设另一位用户并发地在与“a”相同的位置插入字符“x”。在最终的合并结果中，“x”是否会注入到这个反向创建的字符串“abc”的中间？这就是在“反向交错”概念下所研究的问题。

同样地，围绕“多用户接力交错”（multi-user-relay interleaving）——在Fugue论文中也被称为“多副本交错”（multi-replica interleaving）——的讨论似乎也牵强附会。在这种场景中，多位用户依次贡献字符来形成一个字符串。例如，考虑一个假想的场景：用户A输入字符“a”，接着用户B输入“b”形成序列“ab”，最后用户C添加字符“c”完成字符串“abc”。现在，在“多用户接力”交错的背景下出现了一个问题：这个字符串“abc”是否有可能与另一个用户并发插入的字符“x”发生交错？

进一步探讨“多用户接力交错”和“反向交错”的组合变得越来越不可信。这可以通过考察在一个假设场景下文本交错的可能性来证明：用户C启动该过程，输入“c”并接力给用户B，用户B在前面添加“b”创建子字符串“bc”，然后再传递给用户A。随后，用户A 贡献字符“a”，最终形成“abc”。与此同时，用户D在不知“abc”存在的情况下，独立地在与“a”相同的位置输入字符“x”。这就提出了一个问题：字符“x”能否被缠绕进以这种“多用户反向接力”方式创建的字符串“abc”的中间？

这些场景与常见的字符串创建活动（例如自然（正向）输入、复制粘贴、以及离线编辑期间的文本积累过程）形成了鲜明对比，而正是这些活动最初促使人们研究协同编辑中的文本交错问题。因此，质疑这些讨论在理论和实践中的价值是合理的。它们如何才能真正地推动协同编辑技术的发展？它们提供了哪些实际益处？

4.3 拥抱未来：向前迈进

在当前和更广阔的协同编辑背景下，对议题（无论其涉及研究还是实际应用）的相关性和重要性进行批判性评估至关重要。此类评估对于在研究工作和实际解决方案的开发中促进有价值的进步与创新是必不可少的。这些评估可以确保我们的努力是朝着解决协同编辑领域中的真正挑战和机遇方向进行的，从而推动该领域迈向未来。

参考文献

[1]. D. Nichols, P. Curtis, M. Dixon, and J. Lamping: “High-latency, low-bandwidth windowing in the Jupiter collaboration system,” Proc. of the ACM Symposium on User Interface Software and Technology, pp.111–120, Nov. 1995.

[2] C. Sun and C.A. Ellis: “Operational Transformation in Real-Time Group Editors: Issues, Algorithms, and Achievements,” Proc. of ACM Conf. on Computer Supported Cooperative Work, pp. 59–68, Nov. 14–18, 1998.

[3]. C. Sun, “OTFAQ: Operational Transformation Frequently Asked Questions and Answers.”