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