你开心就好

关于看板和画廊，不讨论思源的看板做到什么样，才能达到人们想要的效果这种比较主观的问题了，看板的开发难度无疑是远远大于画廊的，看板本质上就是维度更高的，需要加更多数据划分和更多交互区域的画廊，这一点是客观存在的，现在思源目前只有一个维度，就是表格，当下之急是跨入到另一个简单的维度，也就是画廊，在之后在画廊的功能上进行深化，做到看板，步子迈太大，容易扯着蛋。

这不只是一个 1+1 和二选一的问题

恰恰相反，看板实际上是功能更高级的画廊视图，看板远远比画廊难做多了，以目前思源笔记配套的功能基座去做看板，做出来也只是一个模板，只能看着，你可以看到很多人、很多团队，他们的看板是单独的软件，而不是和文档混在一块儿的，即使是用 notion 的团队，他们也会用单独的 Trello，看板本身当然是非常实用的，可以干这种事情，可以干那种事情，可以管理很多东西，但是说实话，以思源目前的软件基座，做出来的看板可能和想象中的看板不太一样，到时候做出来个残疾看板又要被骂能力不行，如果对看板要求很低，画廊视图完全够用了，多塞几个画廊，不设置封面，也可以做到

看大家都在说看板可以用于项目管理什么什么的，确实是这样的，只是，看板实用，但在思源里可能并不实用，因为思源并没有配套的功能，例如分组，还有时间点提醒，团队进度，还有其他功能等等，开发起来要多费精力，做半天也没有其他专业软件做得好（你可以甚至可以看到专门做看板的软件，并且被广泛使用，例如 Trello），还不如在另一个软件里做项目管理，不然思源里做一个看板功能只是个花架子。画廊的话还能方便管理一下笔记，提供更好的预览视图，不需要太多配套的功能就可以发挥全部的实用性，至少对于思源来说，是比较简单的可以实现各个功能的。所以在我看来，思源里画廊可能比看板实用性更大

把他的话当成是给售后说的就行了，看起来他又不是来社区提问大家求助的，倒是不至于教别人怎么说话

我看没有类似的笔记软件有格式刷的，如果有的话，你记得告诉我一声

其实我觉得这些东西不是审美风格问题，而是放的位置不太符合优秀交互方案，很多按键或者组件就是勉强堆在一起了，没有做很好的循序渐进或者分类

需要一个监听主，否则每个客户端即使拉取同一份数据，由于自己的数据不是都一样的，里面最后就会各有各的保留决策，如果有一个监听主，或者决策主，就好多了

组合一下就行了，一步到位难就打组合拳，jq 提取顶层数据，或用 deepmerge 处理嵌套合并，再结合自定义脚本进一步处理块移动和深度解析，例如顺序重排和解析层数。

但是我有点疲于探讨到底有什么方案和能不能实现了，因为我一开始想表达的只是，这些都会加剧逻辑复杂度，坑也会越来越多，在我们的客户端本来就不能同时并发和及时互相沟通的情况下，性能可能会不升反降。

只要嵌套深度不发生改变，你需要考虑的就只有当前内容对比，不需要考虑内容是从哪里来的，到哪里去了。

如果嵌套深度发生改变，我们也有其他的手段，例如，就像我刚才说的，对于超级块套娃嵌套的取消，我们只关注它最顶层的所有内容，不用非要一次性解析到它最深处。

其实我觉得无法很好的单线展示差异这个坑是超级块埋下来的，因为它使得思源的 json 拥有了向下无限嵌套的可能性，，，但是我们依然可以继续上手段，只做为文档做一次顶层平行解析，超级块或者其他什么乱七八糟的嵌套都只当做一行，然后提供手动调整平行解析深度的选项，如果想更细粒度的“diff”，就增加深度。

但是还是我说的，方案永远用不完，逻辑可以无限复杂，坑也会越来越多

你说的可能是盲合并？但是思源的 json 是有迹可循的啊，远远用不到 AST-patch，自动合并 JSON 并非完全不现实。许多工具和库（例如 jq、jsonmerge、deepmerge）可以合并 JSON 数据。它们可以按照预定义的规则来合并思源块结构，尽管可能不是处理所有情况的万能方案，但对于多数常见场景，尤其是思源的规则较少的情况，完全可行。

但是逻辑上还是会越来越复杂，坑越来越多。

我再插一句，实际上并不只是多端修改同一个文件会导致这样的问题，我亲身测试，甲设备修改 A 文档，乙设备修改 B 文档，然后甲点击同步，甲同步完成之后，乙点击同步，如果乙没有同步完成，甲上线开始打开 B 文档，开始编辑修改，同时乙同步完成了，触发甲的同步，思源目前会直接拿乙修改的 B 覆盖甲的 B，导致编辑内容丢失，且是瞬间发生的，不会有数据快照，如果乙同步完了，甲上线开始打开 B 文档，开始编辑修改，然后点击同步，会直接触发冲突，可怕的是，我们甚至没有在同一时间编辑同一个文档，甚至是在编辑完成之后点击的同步

这是其中一个悖论，也就是文章中提到的一个本质上无关技术的逻辑问题，而要解决这个逻辑问题，你需要更加复杂的技术去勉强解决

我插一句，思源的笔记对于 git 来说一样是纯文本，因为.sy 本质上是 json 而已，就像 git 提交普通的程序代码一样，但是，压缩后的.sy 里面的 json 没有换行，只有一整行，也就是说 git 做不到想 diff 代码文件一样一行一行的显示冲突，但是也不是没有办法细粒度的对比差异，可以直接解析 json 来进行细粒度的对比，我估计性能开销会不小，目前思源也暂时还没有这么做，这个就属于逻辑越来越复杂，坑越来越多的情况，表示理解

牛逼 🐂

非常赞同，这种情况确实不可避免的发生，不同的是中心化服务器在面对各种请求处理时，相比 S3，总可以通过更为简单的逻辑来进行快速且实时的操作来解决问题，随之而来的就是成本增加，开发成本与设备成本权衡之下，我现在还是比较认同思源的同步机制的。

不行了睡了，顶不住了，明日再议了

另外我刚刚为了再验证一下，用 Python 做了监听，确实其实平常不会有太多文件发生改变，基本上修改哪个就只改变相关的几个文件，三到四个左右。如果每次只同步这几个文件，然后附件走进度条上传，我相信大多数人是愿意等，也容易理解的，现在，就是什么都还没有改变，只能自己在社区里自嗨一下了。

所以现在的问题是，同步的过程切割了太多不必要的小文件吗？平常编辑 sy 也很慢，或许因为这个？那我觉得附件可以走另一个通道，当他只是一个附件时，总有好的解决方法，常见的是走另外上传，显示上传进度条，而不是和 sy 这种小型文件放在一起进行多余的操作

或者说，到底什么情况下，需要打这么多的块文件？数据回滚吗？

但是这不是同步机制的问题。

可能我觉得数据结构和同步机制也有关系？话说这种结构不就是为了同步而生的吗？本地使用，软件读取明文，备份也是直接 copy 目录或者导出 sy.zip，我可能理解不到，客户端读取数据是基于这种数据结构的？

在这里的语境中，我指的是建立快照时，产生的数据分块，

那我是理解错了，我以为是 sy 里面的块结构，但是好在，你说的很多数据库会产生，我也做了假设

运行时文件是指与文档本身无关的数据库和索引
中间件处理对接是指监听 api 和文件变动对象
很多数据发生了改变是指你说的我打几个字 net 里会有一堆调用内核 api 的情况

而且假设你说的也对，我打几个字就是会产生很多小碎片，如果说，用户打了几个字，只动了一个思源文档，但是思源产生了一堆数据块，这个作为一个个人使用的本地软件，不是一种冗余吗？要怪在用户不了解的头上吗？

我不明白你提到“块”这个概念是为什么，首先，索引不会校验“块”而是文件，根本没深入到这个数据结构，“块”的改动只是触发扫盘索引而已，我自己 win 下用 bat 写个监听，日常使用中，根本没有几个文件会发生改变，而是几个文件在“高频”改变，这些文件本来就是运行时文件，而思源不通过中间件处理对接，反而放在了同步里面，内核我也看，很多数据发生了改变=很多文件发生了改变？

我想向你描述的很清楚了，包括你现在又说伺服，我一开头表达的很清楚

同步目前最简单粗暴的增本增效的方法就是，直接在服务器上给每个订阅用户运行自己的思源内核实例，在使用官方同步的情况下，客户端后端直接与云端内核通信，离线状态下客户端自己记录距离上一次同步的离线时间戳，每当与云端内核连接，就开始对比数据新鲜度，而冲突解调在云端内核进行

代表我不是不知道伺服可以最快解决，但是你不能作为一个官方订阅，让用户自己伺服吧，所以我直接说了云内核，增本增效。

但是说实话，就做一个最简单的同步，单纯从打开窗口或者后端 api 请求判断哪个 sy 文件发送了改变，上传了哪些文件，删除了哪些文件，禁止 fs，真正的按需同步，也比现在快，大家当然想要如果修改了 3 个字，就只做同步 3 个字的操作，但现在恐怕连修改了 3 个字就只同步这个文档的操作都没做到

这个是想表达，储存器性能根本不是原因，是自己没做足够复杂的中间件处理，最为全世界广泛应用的技术，对象存储已经是最好的云端存储方案了，就好像是，能不能让博尔特再快 5s，这样我看他跑步时间就更短了，有没有可能是自己阈值太高？

然后就是，我也没有把 live 看成是什么标杆，它也是早轮子而已

说白了，你觉得很简单的东西，像 live 做的监听对象，思源加了没有？最后我说这么多，我觉得最核心的还是这个

从去年讨论到现在，关于同步已经讨论了无数多个先进方案了。我的评价是，别自嗨，主要看 D 怎么说

所以你是觉得这样就算结构化了嘛。那这个要求和难度都不算太高，改善也不大就是了。这个实现无论是轮询还是系统监听都能做到，但是还是如上面所说，这方面再怎么改善也是提高了在快照上传到云端前的快照建立速度，但无论什么情况下，基本快照建立都不是主要时间。oss 的并发上传限制、思源保守的云端锁、快照分片数量、本地索引校验机制，无论哪一个的改善都远远比这个显著。

我个人觉得恰恰相反，这个不是为了减少本来就不慢的建立快照的时间，而可以解决我同步的时候，我直接知道我应该同步哪几个文件，而不用还要携带本来就应该是中间件写入储存器之前，供中间件自己建立同步流程用的零零碎碎的小文件，以及可以在让客户端拿到数据时尽量目标明确的去校验特定的文件

至于插件，插件确实会产生很多新文件的，特别是你进行了批量更新。一个插件最少带有 5 个文件，以我这里的例子来说平均是 29 个（49 个插件 1454 个文件），一次批量更新我们假设是 10 个插件，那么就会产生 300 个文件变动，假设每个插件只实际更新 50% 的文件内容，那么会实际产生个 150 文件变动。150 个变动文件假设大小都不大，每个产生一个分片，那么就总计 150 个分片、150 个文档索引、一个最新索引，在我的设备上，这个数据量意味着 300/20 = 15s+4s 总共 19s 的同步时间。当然，这是最好的情况下

有一点跑分测试的嫌疑了，实时上，批量更新插件，拉库这些，我相信大部分人都是主动点击之后在《等》的，也不是天天在点击，并不是影响平常同步体验的关键因素，ob 之前拉库更慢，一个小时都有，耐不住平常同步就是快啊，平常我按照十几个插件，他们也不会突然就产生或者修改几十个文件，一般涉及到这些操作，大部分用户都是主动点击然后《等》，反而不是最关键的因素，关键是因素是平常我就打几个字同步都这么慢

我觉得对等点本身就是一个服务端了吧……硬要这么说，思源也可以内部塞一个 webdav 或 s3 实现，然后直接通过局域网发现协议互相找到端口，进行同步。但是这种情况下思源自己就成为服务端了，这跟思源作为伺服的区别有多大呢？

区别就是思源只是现在的思源，而不是你口中的“要是怎么怎么样就行了”“思源也可以怎么怎么样”

然后就是关于你提供的代码定位，我当然可以跟着你看代码，可以看到，光是监听就写了

        plugin.registerEvent(plugin.app.vault.on("modify", this.watchVaultChange));
        plugin.registerEvent(plugin.app.vault.on("delete", this.watchVaultDelete));
        plugin.registerEvent(plugin.app.vault.on("rename", this.watchVaultRename));
        plugin.registerEvent(plugin.app.vault.on("create", this.watchVaultCreate));
        //@ts-ignore : Internal API
        plugin.registerEvent(plugin.app.vault.on("raw", this.watchVaultRawEvents));
​

五个，每一个事件不只是一个触发器来触发进行扫盘索引，而是拥有具体的返回对象，例如

   watchVaultChange(file: TAbstractFile, ctx?: any) {
        this.appendQueue([{ type: "CHANGED", file }], ctx);
    }

​

通过将文件的修改事件封装成一个对象，这个方法能够为后续的处理提供结构化的数据，这至少是一种基本的处理，至少是和操作挂钩了，返回校验也不需要重新牵一发而动全身

其他的我就不细看了，要休息

我们先假设，你这个测试是有意义的，思源是因为批量小文件拉慢了速度。那么，批量小文件不应该只在第一次下拉数据的时候吗？为什么要对批量小文件是对象存储应该考虑的问题？或者说，思源为什么每次同步都产生这么多批量小文件？我平常手写一秒只在一篇文档里写几个字，上传两三个附件，我真的修改了这么多的文件？人不是机器，很多人做不到无影手一下子修改那么多东西，哪怕是插件，也没有几个会平常一下子修改几十个文件，如果是因为自己的机制，每次一定要产生这么多校验文件，还真就是机制没做好