【TW前瞻】MultiWikiServer 锐意开发中的官方多维基服务器，未来可期

FSpark

目标

同时托管多个维基，并通过“配方/袋子”机制在它们之间共享数据
改进了文件上传和附件的处理，允许上传和流式传输千兆字节的视频文件
服务器和所有连接的客户端之间的更改即时同步
服务器上的工作流处理，例如自动压缩图像或存档网页
强大的身份验证和授权选项

配方/袋子模型

TW越来越像海鲜市场了（笑）
顾名思义，把 Tiddlers (小鱼）装进 Bag（袋子）中，再根据不同的 Recipe （配方/食谱) 组合再与 Template （模板）一起渲染（烹饪）成最终的 Wiki （菜）。

以下是官方定义的规则：

“条目”被存储在命名的“袋子”里
袋子有访问控制，决定哪些用户可以读取或写入它们
配方是按优先级从低到高排列的袋子的命名列表
配方中的条目会按照优先级顺序，从每个袋子中依次收集。因此，如果不同袋子中有标题相同的多个条目，则会使用优先级最高的袋子中的条目作为配方的条目
托管的维基是通过将相应配方中的条目拼接到标准的TW5 HTML模板中来构建的

入口界面

初始界面为多wiki（配方）的入口，配方即为袋子的自由组合（依照顺序级联覆盖）

存储结构

服务端一改以往的 tiddlers 文件夹，转而使用单一SQLite数据库文件。
46deea4a-f4f2-493d-a73b-0a9fbc00b4a2-Snipaste_2024-02-02_13-55-40.png
025b9c23-9802-4805-bcef-7d75b4d58b87-图片.png

内存占用

因为不再将所有tiddlers常驻内存所以大幅减小。
c3967046-a907-4c52-8a2a-b5d721182ddc-图片.png

尝鲜

git clone https://github.com/Jermolene/TiddlyWiki5.git --branch multi-wiki-support
cd TiddlyWiki5
pnpm i
node ./tiddlywiki.js ./editions/multiwikiserver --listen port=8080

再看看

Developer demo of alternate wiki store implementation by Jermolene · Pull Request #7329 · Jermolene/TiddlyWiki5 · GitHub
- 浏览器中的WASM SQLite存储

机杼

厉害了。未来多用户应该会很方便了。

FSpark

其实更大的期待在于性能的巨大改进上，只是目前还不好基准测试

机杼

就是SQLite格式不如tid格式更方便查看。

linonetwo

这个应该是类似 tiddlyhost 的服务器端用的，用于云同步备份、部署博客等等，本地还是可以用多文件版。不过应该也可以用一个同步适配器同时保持 tid 和 SQLite，便于查看和git备份，这个还有待实现。

机杼

@FSpark 我把你这篇文章收到太微漫游文档里了。也搞了一个太微前瞻的分组。

话说原来Jeremy Ruston的github名称是Jermolene，怪不得前者jeremy翻译成杰里米，后者jermolene翻译成杰莫林。之前竟然都没发现。我还以为是浏览器翻译不靠谱啥的。

oeyoews

@FSpark 尝试安装了一下，这 better-sqlite 的依赖好多，先是需要全局安装 node-gyp, 然后又依赖一堆环境（window上一般都没有这些东西），测试还是linux 方便。暂时不试了。

机杼

刚启动成功了，但没搞明白是怎么用的。

机杼

我大概明白怎么用了，简单概括如下

一个bags必须要有一个recipe，不然这个bags无法形成域名，也就无法编辑
一个recipe可以有多个bags，但至少有一个，不然无法构建
recipe中的bags有优先级。同样的标题条目，优先级高的被recipe使用，低的无效。
- 这样带来的一个好处是，你可以自己做一个定制化的wiki模板，然后维护这个模板
- 接着你在你的其他生产环境中使用这个模板，但有些功能你当前的生产环境你不需要，所以你可以直接修改你当前生产环境的内容，不会影响到你的bags条目
- 另一个更常见的好处是，当你更新你的模板时，其他使用该模板的recipe会直接更新，这样就不需要一直调整了

目前存在的问题

文档上说会跟用.tid展示内容不冲突，但没有具体说明如何处理
- 因为显示可以与git相结合
目前recipe和bag没有删除选项，可能是还没有做
目前插件也作为bags提供，这个方案有点不那么好。因为插件太多了，会有很多个bags。如果把CPL收录的插件提供过去，那有好几百个。上百个bags显示的就很糟糕了。
怎么与筛选器结合，这一点还没有说。目前来看，bags与筛选器无关，出现重名的条目，就按优秀级来处理。

可以期待实现的

个人知识库管理会更加高效
举例来说，我可以只在一个book-info的bags中更新书籍信息，而其他的什么都不管，当我需要查询书籍的信息时，我可以在book-info中查找，也可以直接在我的主知识库中查找。
以及上述实现的模板功能。我可以有一个template，里面包含了大量我自定义的功能，但没有打包成插件。而且这里可以是一个生产环境，我可以直接在这里测试。但有个可以预见的问题是，测试条目也会随之附带到main中，所以需要通过筛选器来结合处理。
减轻性能。虽然我不知道具体是怎么处理的，但可以预见的好处是，性能会得到极大的改善。当然这个可能需要测试。
多用户处理
- 比如论坛上很多个不同的wiki，估计就可以使用这种方式来处理展示了，但背后又涉及到git方面的内容，估计还是不行
- 可能需要服务器，这个有点麻烦。因为文档中举了一个老师的例子，老师可以把他的教学资料放在一个bags中，而学生可以每个人都有一个自己的bags，可以提交作业。然后老师查看且修改。理论上都没有问题，最大的问题在于，是老师去部署这个服务器还是学校，学校真的会这样做吗？
- - 这个肯定是学校部署的，老师估计是类似跟用学习通一样。算了，这方面还是不过多讨论了。

感觉等技术成熟了，太记应该可以把这个放进去，从而构建更强大的TiddlyWiki。

太微中文论坛

【TW前瞻】MultiWikiServer 锐意开发中的官方多维基服务器，未来可期

目标

配方/袋子模型

入口界面

存储结构

内存占用

尝鲜

再看看