重构兼容性问题

[LasmGratel]

Core 太臃肿，很多功能都不需要
API天天更改导致每次更新都要重构一万遍 特别不适合长期维护
建议还是把 Protocol 有关部分的基础封装单门拆出来，什么 Event Bus 和 Coroutine 相关的东西放在其他地方
我从 mirai 1.1 版本就开始用了，每次你们更新我都要花五六个小时的时间去迁移排查

还有协议相关内容能否单独更新，独立使用

[LasmGratel]

还有 MessagePacketSubscribersBuilder 被重命名成 MessageEventSubscribersBuilder 了，reply函数也不知道跑哪去了
我不知道这样天天改有什么意义，这是一个不小的库了，应该明白少重构的道理，多标记 @deprecated 少重构
现在就是开发者炫技的工具，而不是一个真正带来长期应用价值的程序

[Him188]

2.0-Mx 是 pre-release 版本没有兼容性保证并早在 2.0-M1 就说这是重构, 你可以选择不更新. 2.0-RC 起才有兼容保证.

mirai 底层就用协程, 不可能不带协程库. 协程是 Kotlin 语言级特性. 而在 Java 不需要考虑协程.

事件是必须要提供的. 否则你如何得到消息事件.

协议底层修改更频繁而且实用非常复杂, 只是你没有看到而已. 如果真的只暴露协议给你, 你很大概率不会用, 而且每个版本都要改.

例如 MessageSource 是内部重构了三遍才得到的这个 API, 群和私聊的发出和接受, 在线和离线全部在协议上不同, mirai 内部有十几种实现, 你难道要自己处理这些吗?
群图片和好友图片内部区别很大, 是 mirai 帮你处理了 ID 才能提供简单 Image 接口.
mirai 马上要支持更多来源的临时会话, 前几天研究过, 也有十几种接口, 你希望每个都来你自己处理吗

拆模块会大幅增加 mirai 要做的工作.

[Him188]

还有 MessagePacketSubscribersBuilder 被重命名成 MessageEventSubscribersBuilder 了，reply函数也不知道跑哪去了
我不知道这样天天改有什么意义，这是一个不小的库了，应该明白少重构的道理，多标记 @deprecated 少重构
现在就是开发者炫技的工具，而不是一个真正带来长期应用价值的程序

这是在 2.0-M2 被弃用的, 因为 Kotlin 编译器不支持, 2.0-RC release note 清楚写到你需要依次升级 2.0-M1 -> 2.0-M2 -> 2.0-RC

[LasmGratel]

那请您告诉我哪个版本可以稳定用下去。

[Him188]

就按前几天分片消息解析来说, 内部接口几乎全改了, 而你用的 sendMessage 还是那个 sendMessage

[Him188]

https://github.com/mamoe/mirai/blob/dev/docs/Evolution.md#%E7%89%88%E6%9C%AC%E8%A7%84%E8%8C%83

[LasmGratel]

为什么要全改掉？原来的不能用？还是QQ协议大变动？

[Him188]

为什么要全改掉？原来的不能用？还是QQ协议大变动？

原来的不能用, 协议比你想象得复杂很多

我昨天就想在 IMirai 接口提供底层 API, 但我发现是在过于复杂而无法对消息相关提供

[LasmGratel]

你说的都没错，可是旧版不是登陆不上就是发不了图片/发不了信息
因为你的协议更新和core是绑定在一块的
如果我想要稳定的协议体验就要更新到最新的dev版本，这岂不是很搞笑

[LasmGratel]

我不想要各种炫酷的功能，也不想要更优化的API 或者DSL 或者什么什么 这些都没用
一个稳定的机器人要求稳定的API 而我在一年内都没有看到稳定版的出现
我甚至不需要你的底层代码写的有多好

[Him188]

1.x 就是稳定版

[LasmGratel]

如果我告诉你1.x已经没法发图了呢？

[Him188]

进行 2.0 重构是因为内部架构过于混乱导致非常难开发新功能

[LasmGratel]

如果我告诉你1.x被封号的几率特别高呢？

[LasmGratel]

那现在的内部架构就不乱了吗？2.0的会让你觉得特别清晰一目了然？

[LasmGratel]

我觉得你都没有自信说2.0会让新功能的开发更加方便。issues下面那么多功能申请你确定2.0就会更快的完成了？
或者说真的有必要实现那么多功能让它变得无比臃肿，最后你也没法维护导致弃坑？

[Him188]

你好, 这个自信我是有的

[Him188]

所有维护者写这东西并不是为了你, 而是出于自己的兴趣

[LasmGratel]

那你可以去找 Vue 作者谈谈。

[Him188]

我觉得没办法和你交流. 我已经做到了我该做的----

• 2.0 重构发布的是 pre-release 没有强制要求更新
• 2.0 解决了 1.x 的架构问题
• 2.0-RC 起会提供源码和二进制兼容

而你却希望我在 1.x 的屎里每天委屈自己为你兼容

[Him188]

? 有必要原因啊, 每个修改都有原因

[koiNoCirculation]

java的Thread的stop, suspend, 等方法，从java1.5一直保留到了java 11，期间经历过10年，为什么没人改，你应该知道的。

[LasmGratel]

我也没法和你交流，毕竟一个不注重真正的开发体验和用户体验只顾自己写的爽的开发者道路也走不长远

[Him188]

很明显我一直都在考虑体验

[Him188]

1.x 的代码是我刚学习 Kotlin 写的, 质量非常差, 是已经在实践过程中遇到了阻碍后续发展的问题

[LasmGratel]

行了行了知道你在学习 Kotlin
学到啥就往软件里用啥

[n0099]

u1s1，mirai-http的api不香吗

[Him188]

由于俩人已经开始不友善, 我无法继续解释. 我在这里说明:

• mirai 1.x 的代码内部质量很差, 开发组几人都认为很难继续维护, 因此决定重构
• 1.x 还有一些设计原因, 如 MessageSource 不兼容分片消息, Contact 架构不兼容陌生人和临时会话, 消息架构无法支持序列化等
• 2.x 重构现在已经完成, mirai 指定了版本更新策略, 在后续版本升级会保证源码兼容性至少两个版本, 二进制绝对向后兼容

补充: 2.0-Mx 的多个版本都有提供 @Deprecated 迁移方案

[Him188]

我承认 1.x 那时有很多 DSL 且没有很好文档, 现在 2.0 刚刚提供了文档并推进了其他的更简单一些的方式

倒不如说就是因为 1.x 有过多不好的设计, 才会有 2.0 的重构. 消息事件下的那些 reply 方法就是目前 Kotlin 编译器不支持的东西. 在 1.x 通过一些特殊手段实现了, 而在最近 Kotlin 1.4.20 后发生了兼容问题. 因此在 2.0 为了稳定性把他们删除了

[Him188]

@dylech30th

开发者有权拒绝你使用mirai框架

是出于有一些人来提不和善的要求因此开发组不满而写下的. 确实有不恰当的地方, 最近 (可能上周) 我已经删除了.

[Cyl18]

我觉得我会滚去用 mirai-api-http

[n0099]

我觉得我会滚去用 mirai-api-http

[Alceatraz]

真的服了 居然有人觉得手动拆几十种byte[]更好
以前coolq就是一个string，CQCode.extract分析，但是事实证明是coolq没少因为qq更新出现消息解析bug，用了一年十几次因为各种更新出现各种空字符、整句话一个空格、CQCode解析混乱，mirai虽然source导致不能分片等以及还是不够优雅，但是从来没有因为Message系列的功能设计出现解析bug
PS：居然还有睿智用公开API改名字被投诉这么可笑的混淆视听来证明什么，不通知别人就改名字怎么都是你的错误好吧，Mirai的2.0里程碑都不知道pin了多久了 而且自从上了2.0的dev preM 几天之内连着发了十几个版，所有修改都明确写了该如何移植。更不用说基本所有软件的1.x→2.0都是解决初版设计不合理的问题的 必然出现api修改，居然还拿着那种臃肿的大厂领导驱动式项目说事
mysql 8直接引入了完全不兼容的登录协议
elastic6直接废弃type
java禁止违规的反射访问
有问题吗？

Mirai的开发者有权拒绝你使用mirai框架
git不能拉黑人真的便宜了某些人

[Him188]

@dylech30th

（另外说一点，我最无法理解的是您为什么要写一个叫做->的函数，这让我不得不发笑）

这就是我刚学习 Kotlin 时候写的代码, 因此我想把它改掉, 至少要为了稳定性减少这些花哨的东西

“开源”也不应当有优越感

我没有因 mirai 开源获得优越感, 我所说 "所有维护者写这东西并不是为了你, 而是出于自己的兴趣" 是因为 mirai 1.x 的代码是在太渣, 我作为发起 mirai 项目的人之一希望能将它维护得很好才打算重构, 而即使我耐心解释了为什么重构, 他也无法接受, 并一直责问我为什么不提供兼容性... 因为就你所说, mirai 1.x 那样的质量已经没办法提供兼容性了

虽然 2.x 代码仍然不一定好, 但至少以我的垃圾水平能知道它比 1.x 更容易维护一些, 至少现在有文档而且同样有兼容性保障

[PeratX]

一句总结，爱用不用，没人有义务满足用户的任何需求。

[PeratX]

一句总结，爱用不用，没人有义务满足用户的任何需求。

同样的，AGPL v3协议下的库没有权利拒绝任何用户使用，如果你能理解到反对声音大多源于这个高高在上的态度，那么其实也不会闹得很僵

代码是按AGPLv3授权的，但是，我们可以拒绝提供一切支持。

[n0099]

一句总结，爱用不用，没人有义务满足用户的任何需求。

同样的，AGPL v3协议下的库没有权利拒绝任何用户使用，如果你能理解到反对声音大多源于这个高高在上的态度，那么其实也不会闹得很僵

代码是按AGPLv3授权的，但是，我们可以拒绝提供一切支持。

有问题吗？

Mirai的开发者有权拒绝你使用mirai框架
git不能拉黑人真的便宜了某些人

Originally posted by @Alceatraz in #850 (comment)

[sandtechnology]

真的服了 居然有人觉得手动拆几十种byte[]更好
以前coolq就是一个string，CQCode.extract分析，但是事实证明是coolq没少因为qq更新出现消息解析bug，用了一年十几次因为各种更新出现各种空字符、整句话一个空格、CQCode解析混乱，mirai虽然source导致不能分片等以及还是不够优雅，但是从来没有因为Message系列的功能设计出现解析bug
PS：居然还有睿智用公开API改名字被投诉这么可笑的混淆视听来证明什么，不通知别人就改名字怎么都是你的错误好吧，Mirai的2.0里程碑都不知道pin了多久了 而且自从上了2.0的dev preM 几天之内连着发了十几个版，所有修改都明确写了该如何移植。更不用说基本所有软件的1.x→2.0都是解决初版设计不合理的问题的 必然出现api修改，居然还拿着那种臃肿的大厂领导驱动式项目说事
mysql 8直接引入了完全不兼容的登录协议
elastic6直接废弃type
java禁止违规的反射访问
有问题吗？
Mirai的开发者有权拒绝你使用mirai框架
git不能拉黑人真的便宜了某些人

1. “Mirai的开发者有权拒绝你使用mirai框架”，你的自信从何而来，要么你给出相关许可证的依据，要么选择闭源，最终解释权归mamoe所有，要么就不要说这种毫无意义的话

2. 你的比较前提是不成立的，mysql java等每个版本都足够稳定并且易用，也就是完全可以留在旧版本不用新版本，而且相比之下，Java API改动频率是多少，占比是多少？而mirai 1.x的体验相比之下是多少？请问你的这个比较是成立的吗

对于2我只能说一点，mirai的体验是建立在腾讯服务器支持的情况下的，而此外部不可控因素是其他软件所没有的，这也就是体验下降的原因，你可以选择不用或者升级，但是请就事论事说明，这里看起来已经成为了情绪发泄的垃圾场了。