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