看过 Google Docs 之类的应用程序和ShareJS和EtherPad Lite之类的库后，我对实时协作感到非常兴奋，这似乎是使用一种称为操作转换的非常复杂的技术来实现的。
我的问题可能有点奇怪：为什么需要 OT？
我的意思是，在大多数设置中，我们在网络上的延迟非常低——使用 Google Docs、ShareJS 和 EtherPad 等工具，更改几乎立即反映在连接的客户端上。
为什么在服务器端解决冲突和保持同步的解决方案非常复杂？
熟悉命令模式和撤消/重做，在我看来，一个更简单的解决方案是将文档的每个更改简单地实现为具有等效撤消命令的命令。
让客户端在进行更改时提交序列化命令。在服务器端为每个收到的命令分配一个序列号。将应用于文档的所有命令分发回客户端，客户端还维护命令历史记录。
每个连接的客户端都从服务器接收到应用于文档的所有命令，现在带有指示“正确”顺序的序列号，例如服务器接收命令的顺序，以及它们应用于主文档的顺序由服务器持有。
如果客户端在命令号 100 处，并向服务器提交了一条返回为 102 号的新命令，则客户端知道它错过了一条命令 - 然后它简单地对它提交的最后一条命令应用“撤消”命令，应用命令号 101，然后再次应用它自己的命令号 102，从而使事情恢复正常。
如果它落后于几个命令，它会根据需要简单地回滚，然后应用所有错过的命令，等等。
这对我来说听起来要简单得多。
运营转型在哪些方面比这更好？