[ 草案规划 ] 关于拓展层的设想

[SOVLOOKUP]

issues 中大家提出了很多改进建议。但设想，如果将来我们将其全部实现，那么界面和操作肯定会更加复杂，不再轻便小巧。另外有些需求可能是一部分用户需要，但另一部分不需要的，这种冗余性也会增加学习操作复杂度，降低用户体验。

那么如何保证在实现用户特异的需求的同时又保证界面和操作的简约呢？

也许除了插件以外，可以加一种 “拓展” 这种 “拓展” 也是插件化安装开启的，不过是用来拓展 rubick 本身的功能，例如拓展搜索框的功能、动态增加rubick API、Webdav 同步插件和数据等等。

另外利用插件实现API的动态增加，就不会因为本体兼容其他软件的 API 而涉及到纠纷了

[SOVLOOKUP]

插件也可以转化为”拓展层 + UI层“组合的模式。将插件自身功能注册到全局功能注册表中，供插件之间交叉调用

[nxnminieye]

插件也可以转化为”拓展层 + UI层“组合的模式。将插件自身功能注册到全局功能注册表中，供插件之间交叉调用

拓展层可以和现有插件兼容,在preload.js中暴露提供的功能,然后其他需要调用这个扩展层的插件,增加个字段

"runtime": [
    "runtime1.name", "runtime2.name"
 ]

加载扩展层插件的preload.js就可以了

[SOVLOOKUP]

如何在插件开发生产环境中处理插件间的依赖关系?

可能的解决方案:

1. 建立一个开发者中心插件，为开发者提供插件调试环境

2. 处理版本管理的问题，我想可以复用 npm 的包管理系统，让开发者把自己的插件发布到 npm ， rubick 也从 npm拉取插件安装。

[muwoo]

如何在插件开发生产环境中处理插件间的依赖关系?

可能的解决方案:

1. 建立一个开发者中心插件，为开发者提供插件调试环境
2. 处理版本管理的问题，我想可以复用 npm 的包管理系统，让开发者把自己的插件发布到 npm ， rubick 也从 npm拉取插件安装。

这个正是我想搞的，计划把插件全部托管到npm上，通过npm进行管理。目前也正在进行

[renmu123]

这里可以参考obsidian插件的处理方式，插件本身都是开源托管在GitHub中，插件开发者需要pr自己的插件信息到软件的插件.json中。这样可以达成某种程度上的审核，以及不占用额外的看见，缺点介绍国内用户下载可能有问题，可能可以支持码云等国内托管平台

[muwoo]

这里可以参考obsidian插件的处理方式，插件本身都是开源托管在GitHub中，插件开发者需要pr自己的插件信息到软件的插件.json中。这样可以达成某种程度上的审核，以及不占用额外的看见，缺点介绍国内用户下载可能有问题，可能可以支持码云等国内托管平台

so surprise! 这个感觉可以！感谢，有灵感了

[SOVLOOKUP]

jsdelivr.com 有 github 的全球 CDN, 通过这个渠道国内也能正常下载 github 上托管的插件

[woojufon]

github也有镜像源，https://github.com.cnpmjs.org/rubickCenter/rubick/，长期支持，也很稳定

[linonetwo]

今天试用了一下 Cerebro ，他也是基于pm托管插件，结果就能搜到很多七年前的已经废弃的插件，甚至代码仓库都已经公开归档了。所以应该还是需要一个GitHub仓库来让大家能够注册新插件和删除已经无需继续列在列表的插件。

然后为了防止维护者太繁忙，无暇照顾，可以使用 https://github.com/marketplace/actions/git-democracy 之类的东西来让社区投票合并。