Commit 1761c536 by junxiang

feat 完善协作白板的机制描述。

parent 2a545e24
import { AlignEnums, BoardElementType } from "./enums"; import { AlignEnums, BoardElementType } from "./enums";
/*
协作画板核心数据model
*/
export interface IBoardState { export interface IBoardState {
version: string; //总版本号 version: string; //总版本号
id: string; id: string;
......
# 技术路线概要 # 技术路线概要
# 技术路线概要 # 技术路线概要
## 协作白板 ## 1.多人协作编辑器
### 文稿管理
### 主要的功能列表
#### 画布管理
##### 新增 ##### 新增
##### 查看 ##### 查看
##### 删除 ##### 删除
##### 查看 ##### 查看
#### 权限管理 ####权限管理
##### 权限分类
管理权限、编辑权限、查看权限、无权限
##### 开通权限 ##### 开通权限
##### 修改/删除权限 ##### 修改/删除权限
#### 协作 ### 协作
#### 新写作者加入 #### 新写作者加入
``` ```
1.前端打开一个文档时,发送请求给服务端,服务端检查协作列表中是否有当前文档。 1.权限校验,如有权限则拉取文档内容。
2.如果有则把当前用户加入此文档修改者列表;如果没有就把当前文档加入协作列表,同时把当前用户ID写入其中。 2.ws通知其他正在修改同一个文稿的人,有新的协作者加入
3.服务端通过长链接给文档列表中的所有其他用户推送消息,告知大家有用户加入协作。
``` ```
#### 数据提交 #### 数据提交
``` ```
1.前端把修改数据发送给服务端 1.前端把修改数据发送给服务端
2.服务端暂存多个用户的操作,并根据OT算法把用户操作合并,最后和数据库存储的文档内容合并 1.1 将变更请求变为阻塞的同步请求
3.把合并完的文档内容保存到数据库中 1.2 前端每次请求都生成连续递增的ID,服务端判断如果递增ID不连续了,就短暂的等待
4.服务端根据文档ID,读取协作列表中的用户,给所有用户发送合并结果 1.3 服务端队列接受,按照连续递增的ID消费。
5.客户端把合并结果与本地文档内容合并
``` ```
##### 合并冲突 ##### 合并冲突
##### 协作通知 ```
1.服务端OT算法合并
2.把合并完的文档内容保存到数据库中,并生成修改记录
3.通过ws给所有的协作者同步最新结果
4.客户端merge云端和本地内容,渲染
```
##### 离线暂存 ##### 离线暂存
本地通过队列暂存请求失败的数据包,每30S重试一次最小序号的包,如果成功提交则进行下一个
#### 备注
OT算法https://zhuanlan.zhihu.com/p/634121875
## 2.协作白板
### 画布资源管理
增删查
#### 权限管理
读取权限、修改权限、删除权限
### 协作
#### 数据提交
```
1.creator区分作者
2.creatAt和id递增确保数据按序上传
3.zIndex用于处理不同素材层级不同,默认按照添加id的顺序来排序。
```
##### 合并冲突
```
元素的颜色填充、尺寸、坐标等属性协同修改,
本质是对数据model对象的协作修改
复杂度相较于文本协作这种单维度(文本任意一个元素可以通过一个单维向量来定位到,但是画布除了需要确定某个元素被修改、还涉及到修改元素的任意属性,合并以及冲突处理的逻辑会复杂很多)的场景直线上升
1.如果某个对象/属性冲突,尝试按照时间顺序单纯覆盖,而不是融合。例如某个笔记里面的文字颜色,a设置成 红色 18px,b在1ms后设置了蓝色。那么关于字体相关的属性,则全部以b为准,设置为蓝色 字体默认大小(例如16px)。a的红色 18px2个属性均丢失。
2.提供一个可选的策略:对象冻结,则某个对象有人在编辑时,冻结该元素,其他人不允许操作。如果有例外情况(同时操作、或者在冻结通知未传输到其他人终端时,他人也进行选中编辑操作(参照上一条原则处理)
```
##### 协作通知
ws
##### 离线暂存
白板暂不考虑离线暂存
### 数据结构化存储/解析 ### 数据结构化存储/解析
``` ```
通过json存取 通过json存取
...@@ -51,47 +83,15 @@ canvas2pdf ...@@ -51,47 +83,15 @@ canvas2pdf
### 进阶 ### 进阶
如果对传输文件大小或者性能有更高要求,可以基于Protobuf协议来替换json 如果对传输文件大小或者性能有更高要求,可以基于Protobuf协议来替换json
## 多人协作编辑器 ## PPT
#### 文稿管理 ### 复用部分机制
##### 新增 + pptist
##### 查看 +
##### 删除
##### 查看
#### 权限管理 ### ppt播放
##### 权限分类 pptJS
管理权限、编辑权限、查看权限、无权限
##### 开通权限
##### 修改/删除权限
#### 协作
#### 新写作者加入
```
1.权限校验,如有权限则拉取文档内容。
2.ws通知其他正在修改同一个文稿的人,有新的协作者加入
```
#### 数据提交
```
1.前端把修改数据发送给服务端
1.1 将变更请求变为阻塞的同步请求
1.2 前端每次请求都生成连续递增的ID,服务端判断如果递增ID不连续了,就短暂的等待
1.3 服务端队列接受,按照连续递增的ID消费。
```
##### 合并冲突
```
1.服务端OT算法合并
2.把合并完的文档内容保存到数据库中,并生成修改记录
3.通过ws给所有的协作者同步最新结果
4.客户端merge云端和本地内容,渲染
```
##### 协作通知
ws
##### 离线暂存
本地通过队列暂存请求失败的数据包,每30S重试一次最小序号的包,如果成功提交则进行下一个
#### 备注
OT算法https://zhuanlan.zhihu.com/p/634121875
## 严肃游戏 ## 严肃游戏
## PPT
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or sign in to comment