| RFC-0098：组件框架 RFC 标准 | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | RFC 流程的附录，定义了组件框架的广泛影响。 |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2021-05-20 |
| 审核日期（年-月-日） | 2021-06-01 |
设计初衷
组件框架 (CF) 系统为在 Fuchsia 上运行软件奠定了基础。除了少数早期启动进程外，从低级系统服务到界面驱动型前端应用的所有软件都是组件，并在组件运行时环境中运行。
因此，对组件框架所做的更改可能会对 Fuchsia 架构以及编写以 Fuchsia 为目标平台的软件的开发者产生广泛影响。
Fuchsia 全局 RFC 流程提供了一个一致且透明的流程，用于做出具有广泛影响的技术决策。本文档旨在提供必要的详细信息，以便区分哪些 CF 更改的影响足够广泛，需要专门的 RFC，哪些更改则不需要。
设计
需要 RFC 的更改
- 导致公共 CF API、库和工具增加或修改的更改，如 Fuchsia SDK 中所述。例如，对
fuchsia.sys2、fuchsia.component、fuchsia.session、CML、C++ 组件库等的更改。 - 安全政策的更改，包括许可名单和 capability 路由。 例如，添加新的许可名单安全政策或添加新的可路由功能。
- 对组件管理器所做的更改会导致外部可见的影响。例如，关闭顺序的计算方式发生变化，或者其性能配置文件（代码大小、内存用量、CPU 时间）发生任何重大变化。
- 对会话管理器所做的更改，会导致外部可见的影响。例如，从平台路由到会话的一组功能发生变化，反之亦然，或者其性能配置发生任何重大变化。
- 引入或移除会话中使用的平台组件的更改，作为 SDK 的一部分。例如：引入一个旨在跨会话重复使用的新“manager”组件。
- Component Manager 的新调试或诊断功能。例如，新的日志分析功能或 Inspect 中的新增内容。
- 提议修改组件架构的更改。例如，引入新的资源管理和配额概念。
- 对 .CML 文件语法的重大更改或添加。例如，更改 .CML 文件表达路由到子项的结构。
如果更改不完全符合上述条件，默认立场是：
1) 遵循 RFC 流程，或 1) 向 Fuchsia 工程委员会寻求反馈
记录现状的 RFC 是可选的，但我们建议您提供。发布现状 RFC 可让更多人（包括 Google 以外的人员）了解 Fuchsia 的现有架构。此外，它们还提供了对架构当前状态的引用，供日后的 RFC 作者链接到。
正例：现在需要 RFC 的过往更改
- 组件解析器 (CTP-013)：引入了 CF 扩展点，让组件作者可以更改组件网址解析为组件元数据和可执行内容的方式。
- 组件 v2 许可名单 (CTP-020)：引入了一种用于控制 CF 运行时的安全政策的机制
- 通过环境路由运行程序 (CTP-021)：提出了对将运行程序功能路由到组件拓扑中的子级和孙级的方式所做的更改
- Realm 构建器（以前称为拓扑构建器 - CTP-033），引入到 SDK 中：一个库，用于在运行时通过测试创建复杂的组件拓扑。
- 新的 CML capability 语法 (CTP-023)：更改了 .CML 文件中 capability 路由的语法
- 将 Stdio 作为 capability (CTP-031, RFC-69)：为 stdout、stdin 和 stderr 引入了新的可路由 capability，并定义了用于上述路由的 .CML 文件语法。
- 从子级使用 (CTP-036)：虽然这是一个小改动，但会影响之前对组件之间路由施加的约束条件。
负例：过去的更改仍不需要 RFC
- 组件框架 API 修订版 (CTP-030)：API 修订版可提高可读性和语义清晰度，而不会更改组件运行时本身的行为。
- 组件管理器可配置性 (CTP-024)：提出了一种新机制来配置 component_manager 的内部行为，以消除通过不太先进的配置机制引入的技术债务。
- 组件图分析 (CTP-034)：在 fuchsia.git 中对组件清单引入了构建时静态分析，以便捕获因人为错误而导致的路由不匹配。
从想法到 RFC
许多功能都需要完成一系列工作，从原型设计、同行提供的设计反馈，到通过生产级代码和 API 获得实际客户体验。CF 贡献者通过不断扩大的受众群体获得功能使用经验，这种情况并不少见。例如，功能提案可能会先经历一个不太正式的设计流程（包括核心团队成员、实现，然后与 fuchsia.git 开发者进行实验），然后再经历更正式的 RFC 流程。
贡献者可以自行选择提前进入 RFC 流程，尤其是在他们能够根据上述标准预测其设计将成为 RFC 时。
实施策略
任何已通过 CF 项目已建立的设计审核流程的工作都不会被要求追溯地遵守此处定义的 RFC 标准。
性能
无影响，仅更改了流程。
工效学设计
如果我们发现这些标准允许通过 RFC 流程更好地实现那些更改，或者发现这些标准过于严格，我们会重新审核这些标准。
向后兼容性
无影响。
安全注意事项
对组件框架区域进行的更改若会修改安全政策或策略，则需要提交 RFC。
隐私注意事项
对组件框架区域进行的更改如果会修改隐私权政策或策略，则需要提交 RFC。
测试
无影响。
文档
不适用。
缺点、替代方案和未知情况
我们尚不清楚本文档中的标准能否在广泛、包容的审核（速度较慢）与更具针对性的审核之间取得适当平衡。
另一种方案是保持现状：CF 团队使用其内部 CTP 流程。