对炸毛框架部分功能的建议

[FishZe]

描述

根据近日交流群内讨论内容和部分个人建议，粗浅整理出部分需求如下:

1. 对不同平台或实现，通过注解或中间件进行不同分发，或在插件的zmplugin.json内进行平台和实现的限制声明.

对于不同的平台和实现，可能会有不同的需求，在每个方法内进行判断较为繁琐，希望框架可以添加规则.

2. 插件声明需要的sqlite数据库并自动创建.

插件可能存在sqlite数据库的需求, 要求插件使用者安装后手动修改global.php较为繁琐, 希望可以自动添加并创建, 并在重启框架后自动连接.

同时, 对于https://github.com/FishZe/zhamao_plugin_what2eat.git 这类使用静态数据的插件, 可否将使用json储存数据改为使用sqlite, 并在zmplugin.json内指定数据库路径到插件目录下呢?

另外, 如果可以在插件内调用数据库时, 不携带数据库名, 而是通过相应插件的配置文件自动选择数据库就更好了, 这样也可以避免不同插件声明了相同的数据库名造成的冲突.

3. 对于不同的平台和onebot实现, 开发相对应的adapter.

onebot协议内要求的内容较少, 有很多扩展消息段和事件等, 对于不同的平台和实现有相对应的adapter使用会方便很多.

如合并转发消息的扩展消息段 / 好友戳一戳 / 处理好友请求等, 开发者如需支持所有QQ平台的实现, 由于 walle-q/onebots/go-cqhttp 实现的字段都不相同, 必须手动判断相应实现, 较为繁琐, 希望有adapter可以实现QQ平台使用较多的扩展内容, 并对不同实现进行统一.

4. 对部分通用配置进行统一管理.

如管理员 / 插件使用权限 / bot名称 / 禁用或启用插件等, 希望框架可以使用配置文件或插件进行统一管理.

5. 在zmplugin.json内声明所需php和框架的版本或安装时检测兼容性

是否可以在zmplugin.json或通过自动检测的方式, 希望框架识别插件所需的环境, 并在安装时进行判断, 防止出现安装插件市场的插件时出现兼容性问题.

6. 插件更新或删除

如对于从github安装的插件, 希望框架可以实现形如./zhamao plugin:update xxx.git的更新方式和./zhamao plugin:remove的删除方式

同时结合上述第5点, 可以在zmplugin.json声明更新需求等.

例子

No response

[crazywhalecc]

1. 对不同平台或实现，通过注解或中间件进行不同分发，或在插件的zmplugin.json内进行平台和实现的限制声明

这个其实应该交给插件方来做，比如插件内注册一个 ws open 的事件，比如在连接检测到 OneBot 12，但连接不是某实现，发出警告或断连。（注意，断连操作需要明确告知）

[crazywhalecc]

2. 插件声明需要的sqlite数据库并自动创建

这个建议是个好建议，鉴于 SQLite 比较轻量，适合携带，所以插件发布时带上一个不大的 SQLite 也是可能的。但引入 SQLite 会要求插件使用者必须启用和安装 pdo_sqlite、sqlite3 扩展，这个需要涉及到框架或 Composer 描述依赖扩展名称。

有关依赖扩展名称，建议使用 composer.json 进行描述，例如：

{
    "require": {
        "ext-pdo_sqlite": "*"
    }
}

这样会在引入插件时，自动 update 假设没有安装会报错。

框架在这里可能需要做的改进就是：对于这种不符合依赖的情况，应该提前在插件安装前告知，并优化报错信息，避免造成信息混乱。

另外一个问题，有关 SQLite 通过 sqlite('dbname.db') 方式使用我觉得可以提上日程。大致流程就是，#Init 事件内调用 PluginManager，将插件的初始库解压到 zm_data 的对应插件目录，然后可以使用例如 zm_sqlite('dbname') 的方式读取插件自身的数据库。

[crazywhalecc]

3. 对于不同的平台和onebot实现, 开发相对应的adapter

这是个世界性难题，现在几乎每个 OneBot 12 实现端都在持续更新，同时同一平台下的接口细节可能也不尽相同。框架能做到的也只是遵循 OneBot 12 标准，标准以外的扩展集合，理论上属于框架之外的部分。鉴于目前框架推荐使用的实现端都有修改的空间，这里其实更建议对目标实现端的项目发起 PR 或 Issue，来协商同一平台下接口数据的细节问题。

[crazywhalecc]

4. 对部分通用配置进行统一管理

炸毛框架的 3.0 工程项目中有一个即将准备开工的插件，pam-core（Plpuggable Authentication Module Core），包含一些对所有插件的每个 BotCommand、Route、BotEvent 的精细管理 API，以及 pam-qq-admin（QQ 管理员组件），包含基于 QQ 和 QQ 群的命令、用户针对性配置功能。如果你有这方面的需求，请将需求详细说明，例如控制粒度、提供哪些 API 接口等，可另开 Issue 或 Discussion。

[crazywhalecc]

5. 在zmplugin.json内声明所需php和框架的版本或安装时检测兼容性

插件系统自带一个依赖声明和检测的功能，例如你的插件依赖 pam-core 插件的 1.x 版本，可在 zmplugin.json 中声明（这个功能已经实现）。

如果需要检查兼容性，可以新建一个单文件入口 main.php，使用 $plugin->onLoad(function() {}); 方法声明自己需要哪些额外的依赖。（onLoad 方法会在扫描插件并加载到插件列表的时候执行，比 #[Init] 注解靠前，执行此方法时框架还没有解析注解事件）。

声明 PHP 版本，可以使用 composer.json 的 require 字段，框架会在下载安装插件时自行检测。

[crazywhalecc]

6. 插件更新或删除

目前插件支持三种方式安装：

1. Composer 依赖
2. Git 拉取
3. Phar 直接使用

第一种 Composer 依赖更新插件较容易，只需要执行 composer update 即可。

第二种 Git 拉取可能比较复杂，而且框架目前也没有标记该插件的安装来源。理论上如果是纯配置 0 代码即可使用的插件，应该发布 phar 版本。

第三种 Phar 发布的插件，确实可以提供插件的更新服务，但是这样需要让插件开发者提供更新链接或使用统一的 GitHub API。

此外，有关更新命令 plugin:update 理论上可以做一个集合，例如自动识别插件类型并对不同类型的插件进行更新，但会导致一个问题，就是插件的开发者在开发自己的插件时，也会绑定 Git 路径，从而导致更新的版本比自己开发的旧出现问题。

总之，更新插件应该只有两种方案可行，其一：全部使用 Composer 安装插件，需要插件开发者将插件发布到 packagist 网站；其二：Phar 发布的插件需要在插件内声明标准的 GitHub 插件仓库，框架将主动调用 GitHub API 查找最新版的版本号并获取下载链接进行下载。

有关插件的删除，这个简单，识别插件类型，找到插件目录，删掉，去掉依赖，完成。