[skip ci] [draft] refactor: 完全重构 Onebot11 适配器 #1245
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
非常好的重构，把gocq adapter收拾的很干净。有个疑问，对于处理失败的事件，是打算仅在主页滚动日志里打印吗 |
有没有什么更好的建议？目前尚且对此没有什么思路。 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
对Onebot11适配器进行重构。思路及选型目前如下：
思路
采用类似SocketIO的事件驱动机制，结合一点“消息队列”的思路实现。Onebot请求首先被区分为“上报事件”和“API回应”，之后根据不同的事件，分发给不同的代码进行处理。
处理消息时，采用gjson来避免序列化成结构体，可读性相对于结构体降低，但极大的增强了适配性。当数据只要包含关键信息时，就能保证进行处理。
处理结构目前为：serveOnebotEvent(分发不同的事件)->onXXXXEvent（针对某一个事件的处理）->handleXXXX（针对某一个事件的子类进行处理）->messageQueueXXXXX(如需要，是否需要有一个消息队列等待消费后做进一步处理，比如加群，加好友，发送好友致辞等）
在API响应处理的实现上，针对需要API响应的数据检查其回应，并根据echo字符串进行切分，若发现其是某个流程（如：加群时，首先确认是否允许加群，而后获取群信息，将群信息的群名称拿到LOG内）的数据，则将其转发到对应的消息队列中。
目前已有两个5s消费一次数据的消息队列（加好友和加群），使用这种方式保证所有加好友/群信息能恒速被处理，避免了同一时间同意过多导致崩溃的问题。
进度
目前功能完成度：
页面
对接功能
控制和连接
可能会考虑的额外功能
当前为群主，无法退群或需要二次确认 #950可能相关的主题
似乎考虑设计一种回调。感觉和目前我的部分设计有相似之处。（怎么之前我没看见这个issue额）#520