回顾了一个知乎老问题《实现一个多人协作在线文档有哪些技术难点?》
发现里面提到的难点 Loro 几乎全解决了:
- 并行编辑冲突
- Undo/Redo。Undo 和历史回放还不太一样,它需要只 undo 用户本地自己的操作。为此我们还在 Loro 这 CRDTs Lib 里面再实现了一套 OT,有专门的 Fuzzing Tests 去覆盖 undo/redo 的正确性。
- 光标位置同步。
- 网络状况,离线重连,操作到达顺序(用 Loro 完全不用关心了,本地始终可用,操作乱序 Apply 都能保证一致性)
- 怎么高效存储。Loro 支持很多种导出格式,可以支持用户每输入几个字符就导出对应的 delta updates,也支持导出完整历史+状态的 Snapshot 格式,也有类似 Git Shallow Clone 的导出格式来降低 CRDT 的 overhead。
- 怎么支持版本历史。Loro 上我们有自己的高效的二进制格式来保存完整的编辑历史,这个编辑历史是类似 Git 一样的有向无环图的编辑历史。我们也支持进行类似 Git 那样的分支/Merge。基于高性能的版本切换和版本管理,我们能做出更好用且自然的 undo/redo 以及版本管理的交互体验。
- 离线编辑。本来就是去中心化的算法,天然支持了。
发现里面提到的难点 Loro 几乎全解决了:
- 并行编辑冲突
- Undo/Redo。Undo 和历史回放还不太一样,它需要只 undo 用户本地自己的操作。为此我们还在 Loro 这 CRDTs Lib 里面再实现了一套 OT,有专门的 Fuzzing Tests 去覆盖 undo/redo 的正确性。
- 光标位置同步。
- 网络状况,离线重连,操作到达顺序(用 Loro 完全不用关心了,本地始终可用,操作乱序 Apply 都能保证一致性)
- 怎么高效存储。Loro 支持很多种导出格式,可以支持用户每输入几个字符就导出对应的 delta updates,也支持导出完整历史+状态的 Snapshot 格式,也有类似 Git Shallow Clone 的导出格式来降低 CRDT 的 overhead。
- 怎么支持版本历史。Loro 上我们有自己的高效的二进制格式来保存完整的编辑历史,这个编辑历史是类似 Git 一样的有向无环图的编辑历史。我们也支持进行类似 Git 那样的分支/Merge。基于高性能的版本切换和版本管理,我们能做出更好用且自然的 undo/redo 以及版本管理的交互体验。
- 离线编辑。本来就是去中心化的算法,天然支持了。