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