RFC-0104：相对组件网址

摘要

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

设计初衷

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

在密封性非常重要的测试中，以及在经常在新测试软件包中重复使用组件的测试中，使用相对网址尤其有用。

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

示例：Isolated-Driver-Manager

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

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

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

如果没有相对网址，就必须针对每个新测试修改 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 在 build 时生成顶级 realm，以便插入正确的软件包名称。

设计

相对网址的格式

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

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

例如：

相对网址：

#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 文件进行模板化，以便在 build 时解析相对网址，并将绝对网址放置在编译后的 CM 文件中。

这样做有以下几点好处：

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

不过，这种方法也有一些缺点：

• CML 通常不需要模板。
• 在构建系统和 cmc 之间添加了更多集成。
• 随着树外组件可以采用不同的构建系统进行构建，构建系统集成变得更加复杂。
• 如果软件包包含预构建的组件，则不清楚此方法如何运作。

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

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

优点：

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

缺点：

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

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

我们可以为相对网址设置特定方案。这样一来，解析网址会稍微容易一些，因为所有受支持的网址都将是“有效”的完整网址。

优点：

• 更轻松地解析网址

缺点：

• 与网址规范不一致

在先技术和参考资料

网址规范在 网址 RFC 3986 中定义了相对网址。 替代方案部分中考虑了使用此确切规范的情况。