[Enhancement] Follow-up plans

[situ2001]

模块目前是用到了Websocket进行网络通讯，Y.Doc暂存到了node server内存上。目前来看，y-websocket提供的是网络通讯能力，暂存在内存相当于一种持久化。

把这两件事抽离出来，得到两个问题

1. 如何进行网络通信
2. 如何持久化存储Y.Doc

因此，可以假设，用户可以通过贡献点机制，往CollaborationContribution中添加下面方法的具体实现

// registerYProvider(doc: Y.Doc): Provider
// async loadYText(uri: string): Promise<void>
// async saveYText(uri:string): Promise<void>
// async deleteFile(uri: string): Promise<void>

从而使得模块变得更加灵活。

2022/08/28 Update

见下面的comments，个人理解是先解决好协同状态下，文件以及DocModel的打开删除等操作过程，让这个模块更好地融入到该IDE框架。

[situ2001]

当然对于上述的场景，我们还可以深入一步，直接提供协同模式下的FileProvider（比如一般的纯web IDE会提供HTTPFileProvider），定义协同状态的文件的读取、新建、打开、保存、删除等的具体操作。

[situ2001]

Update：跳过这里，看下面的comments

这里有一个假设。假设YDoc存到了某处（某处可以是IDE的Node端），需要加载与更新。

[situ2001]

当前限制

• 仅支持了 IDE 编辑器部分的协同编辑功能

• 暂时仅支持在编辑器编辑文件，未处理外部对 IDE 工作区文件的修改（如 git pull, 用其他软件修改了文件内容） #19

• 未支持 browser-only 与 electron 平台（优先级可以降低），理论上，提供协同模式下的FileProvider（比如一般的纯web IDE会提供HTTPFileProvider）也能解决问题

• 在TextModel与CRDT绑定前（事件EditorDocumentModelCreationEvent发生在EditorDocumentModel创建完成后，而该绑定发生在EditorDocumentModelCreationEvent的handler里，且异步），如果发生了修改（再比如用户迫不及待，还没绑定成功，就开始进行编辑了），将不会生效（绑定后的TextModel文本应为CRDT的文本），甚至容易💥。常发生在跨文件重构的场景下（如F2重命名变量），未试过，不确定是否有问题。我在下面的comment提出了一种可能的解决方法

[situ2001]

后续工作

对于上面的问题，为了能有更好的体验，我想可以按这样继续设计下去

由于目前只协同了文本编辑部分，因此决定Y.Map装着工作区的所有文件的文本（后期可以逐渐迁移到subdoc）。文件的作用仅仅只是用来获取文件信息，以及存储着某一时刻Y.Text.toString()的内容（外部软件可以操作这个文件，具有兼容性。外部发生的变化通过 #19 的方法给apply到Y.Text里头就行了）

记得把CRDT给持久化（目前只是in-memory。。）

根据目前对框架的大体理解，可以试着像下图这么做，加粗部分为暑假实现的部分。

暑假的实现是把协同编辑的功能的加载给套到不同事件上（设想给人穿外套：监听事件EditorDocumentModelCreationEvent，事件发生后（此时DocModel已经创建好了）才开始异步进行绑定CRDT等操作，绑后将CRDT的文字给覆盖到TextModel上）。

TextModel与CRDT的绑定最好是在DocModel创建的时候，而不是在DocModel创建后进行绑定。因此下图，很有可能还要加上自己定义的IEditorDocumentModel

如果要有更好的体验，应该把下面的provider都实现一遍。