也许应当开发一套形如oicq-console的体系更为方便完善生态

[eiriksgata]

我一直都觉得使用node+electron很适合做这种工作，开发一个具有图形界面的oicq-console有很大的优势，oicq-console基于 oicq.js 开发，负责管理调用 oicq-console-plugin 、机器人账号登陆验证处理等。

而oicq-console 则给出 plugin的开发规范，plugin更注重于逻辑的开发。

[leoskey]

是类似酷Q的 主体+插件 这种模式吗？

[eiriksgata]

是类似酷Q的 主体+插件 这种模式吗？

差不多，可以参考mirai-console 的设计。但是我希望oicq-console应该加上每个插件调用的优先级，取消并发的概念，而是有层次的分发给不同的插件来响应事件。

[takayama-lily]

插件化其实是很好的，比如可以借鉴vscode的插件模型，当然这种级别的东西可能不需要electron，web界面就足够了。

至于为什么没搞oicq-console，主要因为：

1. 与jvm相比，node简单轻量并且无需编译，实现自己的业务并非很多人都需要这样一个东西。
2. 没有足够的精力和动力(你来pr就有了)。其实有做过类似的，不过基本限于自用，无生态可言：abot | neonbot

[eiriksgata]

插件化其实是很好的，比如可以借鉴vscode的插件模型，当然这种级别的东西可能不需要electron，web界面就足够了。

至于为什么没搞oicq-console，主要因为：

1. 与jvm相比，node简单轻量并且无需编译，实现自己的业务并非很多人都需要这样一个东西。
2. 没有足够的精力和动力(你来pr就有了)。其实有做过类似的，不过基本限于自用，无生态可言：abot | neonbot

electron主要是面对于不懂编程的用户使用，其作用主要是可以编译成多平台应用，无需下载启动运行环境（其实也就是内置nodejs）和浏览器也能直接使用。 当然electron的开发着实让我难受，主要在于 渲染层和主进程的需要通过通讯处理的形式。

至于插件化的目的主要是让 开发者们更专注于对业务的开发，而不需要再每次都需要去集成 登陆验证等相关操作，比如：自动登陆、管理账号密码，界面等。这些应该由 oicq-console去实现。而且如果一个用户想要在其基础上 添加更多的类似于：签到、自动撤回、定期清理不在线人员等。

至于 abot | neonbot 我没仔细看过，但是 我感觉应该是基于 一套代码上 在其基础上 添加更多的代码以实现更多的插件功能。如果是这样，那么对于不懂编程的用户而言，使用起来就会不适。

关于业务这一块，像我做的骰子系统，如果是涉及到DND 跑团体系的集成，那么业务逻辑和指令会异常的繁杂，我的工作更多的是专注于开发这一块，而像 群黑名单、拉群自动同意等这些功能，应该交给其他的插件去完成。（因此 我也就是会提出为什么会有 插件优先级的问题）

其实我有考虑过去开发oicq-console 但是我对于 前端这一块并不是非常的资深，感觉没什么实力能设计出一套规范，特别是对于ts 这门语言的设计模式。

而对于plugin的设计开发，显然也没有什么好的想法去定义，怎么开发出一个 oicq-console-plugin

[takayama-lily]

看来只有给Icalingua加个插件功能了(不是

[dog234]

2023来考古

[Steve-xmh]

插件化其实是很好的，比如可以借鉴vscode的插件模型，当然这种级别的东西可能不需要electron，web界面就足够了。
至于为什么没搞oicq-console，主要因为：

1. 与jvm相比，node简单轻量并且无需编译，实现自己的业务并非很多人都需要这样一个东西。
2. 没有足够的精力和动力(你来pr就有了)。其实有做过类似的，不过基本限于自用，无生态可言：abot | neonbot

electron主要是面对于不懂编程的用户使用，其作用主要是可以编译成多平台应用，无需下载启动运行环境（其实也就是内置nodejs）和浏览器也能直接使用。 当然electron的开发着实让我难受，主要在于 渲染层和主进程的需要通过通讯处理的形式。

至于插件化的目的主要是让 开发者们更专注于对业务的开发，而不需要再每次都需要去集成 登陆验证等相关操作，比如：自动登陆、管理账号密码，界面等。这些应该由 oicq-console去实现。而且如果一个用户想要在其基础上 添加更多的类似于：签到、自动撤回、定期清理不在线人员等。

至于 abot | neonbot 我没仔细看过，但是 我感觉应该是基于 一套代码上 在其基础上 添加更多的代码以实现更多的插件功能。如果是这样，那么对于不懂编程的用户而言，使用起来就会不适。

关于业务这一块，像我做的骰子系统，如果是涉及到DND 跑团体系的集成，那么业务逻辑和指令会异常的繁杂，我的工作更多的是专注于开发这一块，而像 群黑名单、拉群自动同意等这些功能，应该交给其他的插件去完成。（因此 我也就是会提出为什么会有 插件优先级的问题）

其实我有考虑过去开发oicq-console 但是我对于 前端这一块并不是非常的资深，感觉没什么实力能设计出一套规范，特别是对于ts 这门语言的设计模式。

而对于plugin的设计开发，显然也没有什么好的想法去定义，怎么开发出一个 oicq-console-plugin

个人认为这个事情应该留给社区来讨论和开发，啥都压在作者身上的话难免有点强人所难，作者能做出框架也是很辛苦的了

我觉得如果要方便插件用户来使用和管理的话，可以尝试下面几种方式：

1. 统一出一个插件的开发架构标准，方便与机器人框架对接
2. 将 oicq 或者某一依赖 oicq 的机器人框架通过 pkg 打包成单个可执行文件（个人推荐）
3. 提供一个 WebUI 网页前端，以进行机器人和插件的管理（个人推荐）
4. 使用 GUI 框架（如 Electron）提供机器人和插件的管理（个人不推荐，某些场景上不如 WebUI 里通用）

（如果我有时间的话可以给 NeonBot 把 2 和 3 搞一搞？）