| RFC-0104：相对组件网址 | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 解析为父级组件包的相对组件网址。 |
| 问题 | |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2021-05-20 |
| 审核日期（年-月-日） | 2021-06-14 |
总结
此方案建议将相对组件网址添加到组件框架中。相对网址遵循网址 RFC 3986 规范。初始相对网址实现仅支持包含片段，而不支持包含主机或软件包的相对网址。相对网址是相对于组件最近的祖先实体（具有绝对网址）。相对网址解析器将在运行时解析相对网址，通过查找具有绝对网址的组件的最近祖先实体来确定正确的主机和软件包。
设计初衷
缺少相对网址有损组件的可重用性。组件应该无需修改即可包含在新软件包中和使用。不过，当组件使用绝对网址声明其子项时，这些子项必须始终从绝对软件包中解析出来。如果父网址在不同的软件包中重复使用，可能会导致问题，因为现在父网址和子网址位于不同的软件包中。相对网址显示“我希望该组件始终从同一软件包中解析出去”，从而提高了封闭性和可重复使用性。
在以下情况下，使用相对网址特别有用：在密封性很重要以及组件经常会在新的测试包中重复使用的情形下进行测试。
另一个好处是相对网址很方便。组件作者无需多次重复软件包名称，并且因拼写错误而导致的错误空间更小。
示例：Isolated-Driver-Manager
下面我们来看一个具体的使用场景。驱动程序框架团队希望使用相对网址，以便更轻松地编写隔离的驱动程序集成测试。
以下是此类测试的示例拓扑：
驱动程序框架需要多个测试组件协同工作以进行集成测试。所有这些组件都应从测试软件包中加载，以便一起更新，并且可以访问测试软件包中的测试驱动程序。
如果没有相对网址，则必须针对每个新测试修改 isolated-driver-manager.cm，使其指向该测试软件包的本地 driver-manager.cm 和 driver-index.cm。例如，它会指向：
fuchsia-pkg://fuchsia.com/my-test-package#meta/driver-manager.cmfuchsia-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 中所述的格式。相对网址将基于具有绝对网址的最近祖先实体。
对于初始实现，相对网址仅支持包含片段。最初将不支持声明查询参数、路径或主机名的相对网址。最终可能会支持这些脚本。
例如：
相对网址：
#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 将是空架构“"”的解析器。即将在“component_manager”中实现 RelativeResolver。当 RelativeResolver 解析某个组件时，它会遍历该组件的祖先实体，以查找组件网址不具有相对性的第一个祖先实体。然后，解析器会将相对网址 rebase 到绝对网址。方法是复制绝对网址，并将片段部分替换为相对网址的片段。然后，RelativeResolver 将针对基于后的网址发出解析请求，该请求将正常处理。
遍历多个相对组成部分以查找绝对网址的示例。
以下是 RelativeResolver 解析 #meta/child.cm 的步骤：
- 遍历祖先实体，直到找到第一个绝对网址
- 第一个绝对网址为 fuchsia-pkg://fuchsia.com/my-package#meta/realm.cm
- 通过将相对网址基于绝对网址创建绝对网址。
- 我们的绝对网址为 fuchsia-pkg://fuchsia.com/my-package#meta/child.cm
- 针对我们的绝对网址发出解析请求
- 在这种情况下，我们的请求将由 fuchsia-pkg 解析器正常处理
- 返回解析请求的结果
实现
我们计划将 RelativeResolver 实现为由组件管理器提供的内置解析器。RelativeResolver 将添加到根组件的环境中，以便可供从该环境扩展的任何组件使用。
性能
这对性能的影响应该微乎其微。RelativeResolver 在组件框架内部实现，可在不进行任何 IPC 调用的情况下执行祖先遍历和完整网址解析。
安全注意事项
这对安全性的影响应该微乎其微。需要特别注意相对网址的解析和重新定位。
隐私注意事项
此操作不会对隐私权造成任何影响。
测试
相对解析器将具有单元测试，并且将添加使用相对网址的集成测试。
文档
组件框架网址文档中将添加其他文档。
缺点、替代方案和未知情况
替代方案：在构建时解析相对网址的 CML 模板
实现相对网址的另一种方法是使用模板 CML 文件，以便在构建时解析相对网址，并将绝对网址放入已编译的 CM 文件中。
这样做有几个优点：
- 它不需要更改框架运行时。运行时只处理绝对网址
- 相对网址会在构建时解析，这让构建后分析变得更轻松，因为在运行时无法解析任何内容。
这也有一些缺点：
- CML 通常不需要模板。
- 在构建系统与 cmc 之间添加了更多集成。
- 由于树外组件可以使用不同的构建系统进行构建，因此构建系统集成变得更加复杂。
- 不清楚如果软件包包含预构建组件，这会如何运作。
替代方案：从 /pkg 读取数据的相对解析器组件
完成相对网址的另一种方法是使用相对解析器组件（从 /pkg 读取数据）来解析网址。
优点：
- 解析器功能未在组件框架中实现，因此更加模块化
缺点：
- 需要相对解析器的每个组件都需要在其软件包中包含相对解析器组件，并将其正确连接到 CML 文件中
- 这不利于未来的组件框架安全性工作，即组件不具有对 /pkg 的完全访问权限，而只能访问其组件文件。
替代方案：相对网址采用“relative://”格式
我们可以为相对网址制定特定的方案。这会让解析网址稍微简单一些，因为所有支持的网址都是“有效”的完整网址。
优点：
- 更轻松地解析网址
缺点：
- 与网址规范不一致
早期技术和参考资料
网址规范在 网址 RFC 3986 中定义了相对网址。您可在“替代方案”部分中考虑是否使用此确切规范。