在去CQ化过程中，我在考虑能否拟定一套跨语言的插件RFC出来，方便跨语言框架/插件重用？

[Tamce]

最近我本人也在想着重复造轮子造一套比较简单易用的开发框架起来，降低插件开发成本，并尝试提供插件市场以供使用者搜索和选配。于是萌生一个想法，是否可以在跨语言环境下拟定一个较为通用的插件-框架通信RFC，使得不同语言下框架能共用一些形式的插件；或者在某种语言内先行统一插件，建设一个插件生态出来

[ArcticLampyrid]

您好，我尝试造了个轮子：UBotPlatform 非CQHTTP兼容
目前为Golang、Kotlin、Native（dll）、.NET（实验性，TG群获取）、Python（实验性，TG群获取）等提供了RPC SDK
设计上使用JSON-RPC 2.0的双向通讯扩展协议（仿照 VSCode 的 Language Server Protocol） + Websocket

[ForteScarlet]

考虑一下猫猫？🤪虽然猫猫本质上与CQ码没啥区别

[nnnewb]

老实说有点看不大懂你的意思。你说的框架是怎么定义的呢？

协议实现（原酷Q，现在的等价物可能是 MiraiGo？）——框架（原cqhttp，现在的等价物可能是 go-cqhttp）——插件（原cqhttp的插件，也就是现在所谓的机器人框架）

是这样的结构吗？

还是说

框架（同时也是协议实现，原酷Q+cqhttp，现在的 Mirai/go-cqhttp）——插件（原cqhttp的插件，现在所谓的机器人框架）

第二种情况的话，意思是允许协议实现方同时连接多个插件，插件按顺序处理消息（或者不按顺序）做出操作；按现有的常见实现的话，连接方式可能是 http/websocket；如果再提供个插件市场，那其实就是个类似内置cqhttp的酷Q的东西了嘛。

于是萌生一个想法，是否可以在跨语言环境下拟定一个较为通用的插件-框架通信RFC，使得不同语言下框架能共用一些形式的插件；

现在的 http/websocket 通信方式不是已经语言无关了吗。。如果你的意思是原先的 cqhttp 的插件，现在的所谓的机器人框架，和框架的插件的通信方式的话，那是不是和 onebot 离得有点远。。。因为本质上 onebot 定义的这套通信接口就是个机器人框架了。。