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 会在构建时生成顶级领域，以便插入正确的软件包名称。

设计

相对网址的格式

相对网址应遵循 网址 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 将添加到根组件的环境中，以便从该环境扩展的任何组件都可以使用它。

性能

这对性能的影响应该很小。RelativeResolver 在组件框架中实现，可以在不进行任何 IPC 调用的情况下执行祖先遍历和完整网址解析。

安全注意事项

这对安全性的影响应该很小。需要格外小心，确保正确解析和重新设置相对网址。

隐私注意事项

这对隐私不会有任何影响。

测试

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

文档

组件框架网址文档中将添加其他文档。

缺点、替代方案和未知情况

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

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

这样做有几个好处：

• 无需更改框架运行时。运行时仅处理绝对网址。
• 相对网址会在构建时解析，这样便于在运行时解析任何内容，从而简化构建后分析。

这也有几个缺点：

• 一般来说，CML 不希望使用模板。
• 在构建系统和 cmc 之间增加了更多集成。
• 由于可以使用不同的构建系统构建外部组件，因此构建系统集成会变得更加复杂。
• 不清楚如果软件包包含预构建组件，此操作会如何运作。

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

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

优点：

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

缺点：

• 每个需要相对解析器的组件都需要在其软件包中添加相对解析器组件，并在其 CML 文件中正确连接该组件
• 这与未来的组件框架安全工作相悖，后者要求组件不会拥有对 /pkg 的完整访问权限，而只能访问其组件文件。

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

我们可以为相对网址使用特定架构。这样可以稍微简化网址解析，因为所有受支持的网址都将是“有效”的完整网址。

优点：

• 更轻松地解析网址

缺点：

• 与网址规范不一致

在先技术和参考文档

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