RFC-0104：相对组件网址

摘要

这是一项向组件框架添加相对组件网址的提案。相对网址遵循 URL RFC 3986 规范。初始相对网址实现仅支持包含 fragment，不支持包含主机或软件包的相对网址。相对网址是相对于具有绝对网址的组件最近祖先实体而言的。相对网址解析器会在运行时解析相对网址，通过查找具有绝对网址的组件的最近祖先实体来确定正确的主机和软件包。

动机

缺少相对网址会影响组件的可重用性。组件应该能够包含在新软件包中并直接使用，而无需进行修改。但是，当组件使用绝对网址声明其子组件时，这些子组件始终必须从绝对软件包中解析。如果父级网址在其他软件包中重复使用，则可能会导致问题，因为现在父级和子级位于不同的软件包中。相对网址表示“我希望始终从同一软件包中解析此组件”，这有助于提高封闭性和可重用性。

使用相对网址在测试中特别有用，因为在测试中，封闭性非常重要，并且组件通常会在新的测试软件包中重复使用。

相对网址的另一个好处是使用方便。组件作者无需多次重复软件包名称，并且因拼写错误而导致错误的空间更小。

示例：Isolated-Driver-Manager

我们来看一个具体的应用场景。Driver Framework 团队希望使用相对网址，以便更轻松地编写隔离的驱动程序集成测试。

以下是此类测试的示例拓扑：

驱动程序框架需要多个测试组件协同工作才能进行集成测试。所有这些组件都应从测试软件包中加载，以便它们可以一起更新，并可以访问测试软件包中的测试驱动程序。

如果不使用相对网址，则必须针对每个新测试修改 isolated-driver-manager.cm，以便其指向该测试软件包的本地 driver-manager.cm 和 driver-index.cm。例如，它会指向：

• fuchsia-pkg://fuchsia.com/my-test-package#meta/driver-manager.cm
• fuchsia-pkg://fuchsia.com/my-test-package#meta/driver-index.cm

使用相对网址时，无需针对每个新测试修改 isolated-driver-manager.cm，只需使用相对网址语法即可，如下所示：

• #meta/driver-manager.cm
• #meta/driver-index.cm

值得注意的是，目前 CFv2 IsolatedDevmgr 会在构建时生成顶级领域，以便插入正确的软件包名称。

设计

相对网址的格式

相对网址遵循 URL RFC 3986 中概述的格式。相对网址将重新定位到具有绝对网址的最接近祖先。

在初始实现中，相对网址仅支持包含片段。最初不支持声明查询参数、路径或主机名的相对网址。这些功能最终可能会得到支持。

例如：

相对网址：

#meta/child.cm

具有绝对网址的最近祖先：

fuchsia-pkg://fuchsia.com/my-package/0/?hash=1234#meta/parent.cm

解析后的网址：

fuchsia-pkg://fuchsia.com/my-package/0/?hash=1234#meta/child.cm

相对解析器

RelativeResolver 将是相对网址的解析器。目前，解析器是针对特定网址协议声明的；RelativeResolver 将是空协议“”的解析器。RelativeResolver 将在 component_manager 中实现。当 RelativeResolver 解析组件时，它会遍历该组件的祖先，以找到组件网址不是相对网址的第一个祖先。然后，解析器会将相对网址重新定位到绝对网址。为此，请复制绝对网址，并将片段部分替换为相对网址的片段。然后，RelativeResolver 将针对重定基准的网址发出解析请求，该请求将正常处理。

一个遍历多个相对组件以查找绝对网址的示例。

以下是 RelativeResolver 解析 #meta/child.cm 的步骤：

1. 遍历祖先节点，直到找到第一个绝对网址

• 第一个绝对网址是 fuchsia-pkg://fuchsia.com/my-package#meta/realm.cm

1. 通过将相对网址重新定位到绝对网址，创建绝对网址。

• 我们的绝对网址为 fuchsia-pkg://fuchsia.com/my-package#meta/child.cm

1. 为我们的绝对网址发送解析请求

• 在这种情况下，我们的请求将由 fuchsia-pkg 解析器正常处理

1. 返回解析请求的结果

实现

计划将 RelativeResolver 实现为由组件管理器提供的内置解析器。RelativeResolver 将添加到根组件的 environment 中，以便从该环境扩展的任何组件都可以使用它。

性能

这应该对性能影响极小。RelativeResolver 在组件框架内部实现，可以执行祖先遍历和完整网址解析，而无需进行任何 IPC 调用。

安全注意事项

这应该对安全性影响最小。需要格外小心，确保相对网址得到正确解析和重定基准。

隐私注意事项

这不会对隐私权产生任何影响。

测试

相对解析器将进行单元测试，并且将添加使用相对网址的集成测试。

文档

我们将向组件框架网址文档中添加更多文档。

缺点、替代方案和未知因素

替代方案：在构建时解析相对网址的 CML 模板

实现相对网址的另一种方法是模板化 CML 文件，以便在构建时解析相对网址，并将绝对网址放置在已编译的 CM 文件中。

这样做有几个好处：

• 它不需要更改框架运行时。运行时仅处理绝对网址。
• 相对网址会在构建时解析，这使得构建后分析更加容易，因为在运行时不会解析任何内容。

这种方法也有一些缺点：

• CML 通常不需要模板化。
• 增加了构建系统与 cmc 之间的集成。
• 由于树外组件可以使用不同的构建系统进行构建，因此构建系统集成会变得更加复杂。
• 如果软件包包含预构建组件，则不清楚此功能将如何运作。

替代方案：从 /pkg 读取的相对解析器组件

实现相对网址的另一种方法是使用相对解析器组件，该组件从 /pkg 读取数据以解析网址。

优点：

• 解析器功能未在组件框架中实现，这使其更具模块化

缺点：

• 每个需要相对解析器的组件都需要在其软件包中包含相对解析器组件，并在其 CML 文件中正确连接该组件
• 这与未来的组件框架安全工作背道而驰，因为组件将无法完全访问 /pkg，而只能访问其组件文件。

替代方案：相对网址采用“relative://”架构

我们可以为相对网址采用特定架构。这样一来，所有受支持的网址都将是“有效”的完整网址，从而使网址解析变得稍微简单一些。

优点：

• 更轻松地解析网址

缺点：

• 与网址规范不一致

在先技术和参考资料

网址规范在网址 RFC 3986 中定义了相对网址。“备选方案”部分会考虑使用此确切规范。