关于 OneBot 实现与应用的抽象模型讨论

[abrahum]

目前社区正在有许多基于 OneBot 的实现端 libonebot 和应用端 SDK 都在开发中，这里仅对 OneBot 协议的底层抽象做一个个人理解的展示，供各位开发者参考讨论。

首先目前对于 OneBot 来说其实可以把一个 libonebot 或者 SDK 分解为三个部分：

• OneBot 实例
• OneBot 数据协议
• OneBot Connect 实现

其中 OneBot 数据协议（既 Event Action ActionResponse MessageSegment）各个语言的序列化与反序列化存在较大差异，在此不做过多讨论。

需要指出的是 SDK 在开发过程中需要充分考虑 OneBot 协议的可扩展性（主要是 Event 模型）

对于一个 OneBot 实例（无论实现端还是应用端），我的抽象模型如下：

对于任何一个 OneBot 实例均存在一个 EventHandler 和一个 ActionHandler，其中 EventHandler 产生 Action 并处理 Event；而 ActionHandler 与之相反。

具体来说对于一个实现端来说， ActionHandler 就是实现平台的对接逻辑代码，它产生来自平台的 Event 并接收 Action 传递到平台进行处理；而 EventHandler 就可以是 OneBot Connect，它接收平台产生的 Event 通过连接对外分发，然后从连接接收 Action（产生 Action ）并传递。

而对于应用端来说，情况正好与之相反

请注意该抽象模型中 Action 可能必须需要扩展 self_id 字段才可以

这个模型可以最大程度上的解耦 OneBot 协议的各个部分，让各部分代码增加可复用性，避免重复工作。

我想到的可能应用到的场景：

• OneBot Connect 增加新的连接方式，只需要维护 libonebot 或 SDK 中的部分
• OneBot Connect 需要增加权限控制、限速、限流等中间层控制，只需要以原 Handler 为基础包装一个新 Handler 即可复用
• 实现端需要添加扩展事件或动作，只需要增加数据协议部分的模型，即可复用其余组件
• 通过编写一个中间层宿主语言EventHandler- 嵌入语言 ActionHandler（或相反）即可跨语言调用并复用所有组件

抛砖引玉，欢迎讨论

[abrahum]

abrahum/walle-core：基于此抽象模型做的 OneBotLib