| RFC-0229：FIDL 2023 | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 目前的 FIDL 传输格式和交互模型（称为 FIDL 2023）将至少获得三年的支持。 |
| 问题 | |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2023-08-29 |
| 审核日期（年-月-日） | 2023-10-11 |
总结
本文档确立，Google 将至少支持现有的 FIDL 传输格式和交互模型（称为 FIDL 2023）至少三年。
设计初衷
FIDL 包含许多东西：语言、编译器、绑定、传输格式和交互模型。此 RFC 关注的是后两项内容，因为它们对 ABI 兼容性至关重要。近年来，这两者都发生了巨大变化。例如，我们最近迁移了 RFC-0113：高效信封的传输格式，并修改了 RFC-0138：处理未知交互的交互模型。之所以能够做出这些更改，是因为我们知道所有使用 FIDL 的代码，因此可以更新它们。将来，随着平台日益成熟，这种情况并非如此。我们需要开始考虑长期 ABI 兼容性。
利益相关方
教员：abarth@google.com
审核者：hjfreyer@google.com、ianloic@google.com、sethladd@google.com、ddorwin@google.com
咨询人员：quiche@google.com、wilkinsonclay@google.com
社交：在撰写本 RFC 之前，FIDL 团队会议中对 FIDL 2023 的计划进行了多次讨论。
设计
此提案的目标是定义 FIDL 2023，并批准自您接受此 RFC 之日起至少三年内为其提供支持的计划。
范围
FIDL 2023 是指截至 2023 年 9 月的 FIDL 有线格式和互动模型的状态。FIDL 的所有其他部分都不在说明范围内。
传输格式指定了线上 FIDL 消息的编码和解码方式。 这包括互动模型中使用的事务性消息，以及通过 RFC-0120 API 进行独立编码和解码的其他用例。我们记录了传输格式，但需要注意以下几点：
- 魔数为 1。对于任何其他魔数，解码必须失败。
- 静态标志包含“v2 指示器”
0x0002。如果未设置该位，则解码必须失败。 - 不得验证其他标志位。解码不得因当前未使用的静态标志或动态标志的值而失败。
交互模型指定了 FIDL 客户端和服务器的行为方式。例如，其中包含以下事实：FIDL 对等方在解码传入消息时必须关闭其通道端点。交互模型还没有全面的文档（请参阅文档），但会在 FIDL dynsuite 中进行测试。
FIDL 2023 包含截至目前所有 RFC 对传输格式和交互模型的变更，特别是以下变更：
请注意，有些 RFC 并未在所有绑定中实现。特别是，尚未针对 RFC-0137 更新 Go 和 Dart 绑定。因此，它们并不完全符合 FIDL 2023 标准。
支持
FIDL 2023 是 FIDL 有线格式和互动模型的长期支持 (LTS) 版本。从接受此 RFC 之日起，我们会为其提供至少三年的支持。
但这并不意味着向 FIDL 添加新功能。只需要保持与 FIDL 2023 的兼容性。此外，如果我们添加任何新功能，这些功能不会自动成为 LTS 保证的一部分。
具体而言，假设有人编译了一个使用 FIDL 2023 的程序。如果“正常工作”取决于 FIDL，则在整个支持期内，该二进制文件应该能够正常运行，前提是：
- 软件堆栈的其余部分（特别是 Zircon 和组件框架）保持类似的长期兼容性；
- 它使用的 FIDL 协议保持不变或以与 ABI 兼容的方式演变；
- 与之通信的对等方会保持应用级兼容性。
下面是一些正面示例（此方案允许）和反面示例（不允许），旨在说明 FIDL 2023 支持的含义。
正例。该程序使用带有结构体的协议。我们向此结构体添加一个字段，破坏 ABI。该程序在与较新的对等方通信时无法解码消息。这未违反 FIDL 2023。
反例。我们更改了传输格式，以便对表使用稀疏表示法。程序无法使用此表示法解码消息。这违反了 FIDL 2023，即使我们使用标志软转换该变更，也是如此，因为这仍然需要重新编译程序。
正例。我们为 FIDL 添加了一个新类型
uint128。程序无法对此类型进行解码。这不违反 FIDL 2023，因为uint128不是 FIDL 2023 的一部分。如果程序使用的协议不使用uint128，就没有问题。如果它们在编译程序后以与 ABI 兼容的方式发展为使用uint128，这也没有问题，因为这些值肯定被封装在信封中或在新方法中。最后，如果对使用uint128的更改发生在编译程序之前，那么程序可以安全地对uint128值进行解码。
正例。我们更改了互动模型，以允许服务器发起的双向方法。这未违反 FIDL 2023，原因与上述
uint128示例类似。
反例。我们更改了互动模型，以允许客户端向服务器发送缩略图。这违反了 FIDL 2023，因为该程序可能会实现服务器，并且无法正确处理此类消息。
这些示例表明，传输格式和交互模型仍然可以更改，但更改必须是新增和选择启用的（例如，选择在新 API 中使用 uint128 类型）。未选择启用新功能的代码必须在 FIDL 2023 支持的有效期内继续运行。
性能
我们承诺对 FIDL 2023 的长期支持，意味着我们无法通过更改传输格式来提升现有功能的性能。
工效学设计
此方案对人体工程学没有任何影响。
向后兼容性
该方案与向后兼容性有关，因此全文（而非本节）进行讨论。
安全注意事项
如果我们发现需要做出不兼容更改的安全问题，则可能会违背对 FIDL 2023 全面支持 FIDL 2023 的承诺。
隐私注意事项
如果我们发现需要做出不兼容更改的隐私权问题，则可能会违背对 FIDL 2023 全面支持 FIDL 2023 的承诺。
测试
我们将继续测试使用 GIDL 的传输格式以及与 dynsuite 的交互模型。我们还将投资发展这些框架，以提高 FIDL 2023 功能和极端情况的覆盖范围。这有助于确保我们兑现长期支持的承诺。
文档
我们必须更新 FIDL 传输格式规范。例如，除非另有说明，否则系统可能会显示所有内容都是 FIDL 2023 的一部分。
FIDL 绑定规范记录了互动模型的某些方面，但混合了有关所生成绑定的结构和样式的指南。我们必须改而创建新的“FIDL 交互模型规范”。它中的每个语句都应由 dynsuite 测试提供支持。
缺点、替代方案和未知情况
缺点：FIDL 改进难度较大
此方案将使改进和改进 FIDL 的难度增大。例如，更改传输格式的成本会更高。我们不仅需要通过标志执行软转换（像之前一样），而且还必须长时间保留旧读取路径，即使我们认为没有任何项目依赖于旧路径也是如此。
替代方案：不同的时间长度
该方案表明，我们会更加重视长期兼容性。我觉得三年比较还合适。这个版本比我们之前提供过的兼容性要长。但背后并没有任何其他用途。我们可以承诺不同的年限。
未知：实际应用 ABI 兼容性
我们仍在学习在实际应用中 Fuchsia 的长期 ABI 兼容性。理想情况下，FIDL 提供了稳定的基础，可帮助开发者改进应用和服务。过去，我们对 FIDL 做出了重大更改，以更好地支持演变性和兼容性，例如在 RFC-0061：可扩展联合体中。FIDL 2023 是否具有上述层提供长期兼容性所需的所有功能，还是缺少某些功能？
早期技术和参考资料
所有成功的操作系统都会提供一定程度的长期兼容性。毫无疑问，Fuchsia 以及 FIDL 也需要这么做。
长期支持版本的概念在开源软件中很常见。例如，Linux 内核将某些版本指定为“长期”。