> 为什么你需要为ASN.1设置支持SLA，而不是PB/FB？这没有意义。现在有很多开源的ASN.1工具——只要看看这个线程！如果你的业务依赖于5G通信栈的五九可靠性，你可能会愿意为此支付费用。或者如果你需要及时修复compiker或运行时的错误，同样如此。正如我上面提到的，我的一个客户就是出于这个原因转向了商业工具套件。根据我的经验，Protocol Buffers和FlatBuffers有不同的使用场景，尽管这可能有些局限。Protocol Buffers在版本2和3之间确实引入了破坏性变更。ASN.1在这方面并不完美，但如今的不兼容性必须经过ISO或ITU等机构。当然，你的体验可能不同。我只是指出人们选择商业产品的理由。
源讨论一种新的Python ASN.1 API原帖 124 条评论 · 导入时统计> 但如果你恰好有一个需要使用ASN.1的用例，开源工具可能会有问题，恰恰是因为需要一个稳健的SLA。 为什么你需要为ASN.1而不需要为PB/FB的SLA？这毫无道理。现在有很多开源的ASN.1工具——只需看看这个线程！
完整原文把你的经验，加入这段讨论。
> 五个九 是否要为每件硬件、固件和软件都支付SLA（服务等级协议）？编解码器是最不可能导致停机的原因。
完整原文> 根据我的经验，Protocol Buffers和flatbuffers有不同的使用场景，尽管这可能有些有限。 这一点对于ASN.1编码规则也适用。 > Protocol Buffers在版本2和版本3之间确实引入了破坏性变更。ASN.1在这方面并不完美， ASN.1什么时候曾经破坏过向后兼容性？我从未听说过ASN.1的向后不兼容性。也许，如果你将1984年的ASN.1解释为允许在`SEQUENCE { }`中添加新字段，那么后来添加的可扩展性标记可能算作一种非常弱的向后不兼容变更——这种弱性在于，使用ASN.1的现有规范必须为实际打算扩展的`SEQUENCE { }`添加这些标记，但没有运行中的代码被破坏。如果ITUT真的破坏了运行代码的向后兼容性，我会非常震惊。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。