| RFC-0229：FIDL 2023 | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 当前的 FIDL 有线格式和交互模型（称为 FIDL 2023）将至少支持三年。 |
| 问题 | |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2023-08-29 |
| 审核日期（年-月-日） | 2023-10-11 |
摘要
本文档规定，当前的 FIDL 有线格式和交互模型（称为 FIDL 2023）将至少支持三年。
设计初衷
FIDL 包含多种要素：语言、编译器、绑定、线路格式和交互模型。此 RFC 关注的是后两者，因为它们对于 ABI 兼容性至关重要。这两者多年来都发生了显著变化。例如，我们最近迁移了 RFC-0113：高效信封的线格式，并修订了 RFC-0138：处理未知互动的互动模型。由于我们了解所有使用 FIDL 的代码，因此能够更新所有这些代码，从而实现这些更改。未来，随着平台日趋成熟，这种情况将不复存在。我们需要开始考虑长期的 ABI 兼容性。
利益相关方
Facilitator: 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。
范围
FIDL 2023 指的是截至 2023 年 9 月的 FIDL 有线格式和互动模型的状态。FIDL 的所有其他部分均不在本文档的讨论范围内。
有线格式指定了如何在有线上对 FIDL 消息进行编码和解码。 这包括交互模型中使用的事务性消息，以及通过 RFC-0120 API 实现的其他使用情形，用于进行独立编码和解码。线格式已记录在案，但仍有一些事项值得注意：
- 魔数为 1。对于任何其他 magic number，解码都必须失败。
- 静态标志包括“v2 指标”
0x0002。如果未设置此位，解码必须失败。 - 不得验证其他标志位。解码不得因当前未使用的静态标志或动态标志的值而失败。
交互模型指定了 FIDL 客户端和服务器必须如何运行。例如，它包含以下事实：如果 FIDL 对等方无法解码传入的消息，则必须关闭其通道端点。交互模型尚未提供全面的文档（请参阅文档），但已在 FIDL dynsuite 中进行测试。
FIDL 2023 包含对所有 RFC 的线格式和交互模型的更改，特别是以下更改：
请注意，某些 RFC 尚未在所有绑定中实现。特别是，Go 和 Dart 绑定尚未针对 RFC-0137 进行更新。因此，它们并不完全符合 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 的承诺。
测试
我们将继续使用 GIDL 测试线格式，并使用 dynsuite 测试互动模型。我们还将投资扩大这些测试的规模，以增加对 FIDL 2023 功能和边缘情况的覆盖范围。这有助于确保我们兑现长期支持的承诺。
文档
我们必须更新 FIDL 线上传输格式规范。例如，它可以说明，除非另有说明，否则所有内容都是 FIDL 2023 的一部分。
FIDL 绑定规范记录了互动模型的某些方面，但其中也混杂了有关所生成绑定的结构和样式的指南。我们必须改为创建新的“FIDL 交互模型规范”。其中的每条语句都应由 dynsuite 测试提供支持。
缺点、替代方案和未知因素
缺点：难以改进 FIDL
此提案会加大 FIDL 发展和改进的难度。例如，更改序列化格式的成本会高得多。我们不仅需要像以前一样使用标志执行软过渡，还必须将旧读取路径保留更长时间，即使我们认为没有任何内容依赖于它。
替代方案：其他时长
此提案表明，我们更加重视长期兼容性。三年期限大致比较合适。这是我们有史以来最长的兼容性支持期限。但除此之外，它并没有太多其他内涵。我们可以承诺不同的年限。
未知：ABI 兼容性实践
我们仍在了解 Fuchsia 上的长期 ABI 兼容性在实践中会是什么样子。理想情况下，FIDL 提供了一个稳定的基础，开发者可以利用它来改进应用和服务。过去，我们曾对 FIDL 进行过重大更改，以更好地支持可演化性和兼容性，例如在 RFC-0061：可扩展的联合中。FIDL 2023 是否具备上层所需的所有功能，以提供长期兼容性，还是缺少某些功能？
在先技术和参考资料
所有成功的操作系统都提供一定程度的长期兼容性。 毫无疑问，Fuchsia（以及 FIDL）也需要这样做。
长期支持版本的概念在开源软件中很常见。例如，Linux 内核将某些版本指定为“长期”版本。