| RFC-0104：相对组件网址 | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 解析为其父级组件软件包的相对组件网址。 |
| 问题 | |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2021-05-20 |
| 审核日期（年-月-日） | 2021-06-14 |
摘要
此建议是向组件框架添加相对组件网址。答 相对网址跟在 网址 RFC 3986 规范初始相对网址实现仅支持将 片段中，它不支持包含主机或软件包的相对网址。亲属 网址相对于组件的最近祖先实体（具有绝对网址）。通过 相对网址解析器会在运行时解析相对网址 正确的主机和软件包： 绝对网址。
设计初衷
缺少相对网址会影响组件的可重用性。组件 应用应该能够在未经修改的情况下包含和在新软件包中使用。 不过，当组件使用绝对网址声明其子项时， 子项始终必须从绝对包中解析出。这可以 如果父网址在其他软件包中重复使用，会引发问题， 父级和子级位于不同的软件包中。相对网址显示“我 始终希望从同一软件包中解析此组件”， 促进保密和重复使用
在测试封闭性的情况下，使用相对网址特别有用 并且新的测试软件包中经常会重复使用这些组件。
另一个好处是相对网址很方便。由组件作者负责 无需多次重复软件包名称 错误。
示例：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.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。 相对网址将重新基于具有 绝对网址。
对于初始实现，相对网址仅支持具有 fragment。用于声明查询参数、路径或主机的相对网址 名称最初不受支持。这些 API 最终可能会受支持。
例如：
相对网址：
#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 在解析组件时，会 遍历该组件的祖先，以找到第一个 组件网址不相关。然后，解析器会对相对地址进行 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。 “替代方案”部分考虑了使用此确切规范的情况。