| RFC-0098：组件框架 RFC 标准 | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | RFC 流程附录，定义了对组件框架的广泛影响。 |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2021-05-20 |
| 审核日期（年-月-日） | 2021-06-01 |
设计初衷
组件框架 (CF) 系统提供了 在 Fuchsia 上运行的软件。除了一些前期启动进程外 从低级系统服务到界面驱动的前端，所有软件都包括在内 应用 组件 并在云环境中 组件运行时。
因此，对组件框架的更改可能会对 Fuchsia 架构以及针对编写面向特定应用的 紫红色。
Fuchsia 范围的 RFC 流程可提供一致且 制定具有广泛影响的技术决策的透明流程。这个 文档力求提供必要的详细信息，以消除哪些 CF 之间的歧义 变更具有足够广泛的影响，值得专门的 RFC， 错误。
设计
需要 RFC 的更改
- 导致对公共 CF API 进行增补或修改的更改；
库和工具。例如，将
fuchsia.sys2、fuchsia.component、fuchsia.session、CML、C++ 组件 等等 - 安全政策更改，包括许可名单和功能路由。 例如，添加新的许可名单安全政策，或添加新的 可路由功能
- 对组件管理器进行了会导致外部可见的更改 效果。例如，关停顺序的计算方式发生了变化，或 性能配置文件（代码大小、内存用量、CPU）的任何重大更改 ）。
- 对会话管理器进行了更改，这些更改会导致外部用户看到 效果。例如，从 反之亦然， 效果概况
- 引入或移除会话中使用的平台组件的更改，例如 是 SDK 的一部分。例如：介绍一名新“经理”组件 以便在不同会话中重复使用
- 组件管理器的新调试或诊断功能。例如： 新的日志分析功能，或者是“检查”中的新增功能。
- 提议对组件架构进行修改的变更。对于 示例，介绍新的资源管理和配额概念。
- .CML 文件语法的主要更改或添加。例如，将 .CML 文件向子文件表达路由的结构。
当变更不能完全符合上述标准时，默认立场是 更改为：
1) 遵循 RFC 流程，或 1) 向紫红色工程委员会寻求建议
记录现状的 RFC 不是强制要求，但我们建议您提交。发布 现状 RFC 扩大了对 Fuchsia 现有架构的认识， 包括 Google 以外的个人。 此外，它们还提供了对当前架构状态的引用 供未来的 RFC 作者链接到。
正面示例：过去现在需要 RFC 的更改
- 组件解析器 (CTP-013)：引入了一个 CF 扩展点，以允许 组件作者更改组件网址解析为组件的方式 元数据和可执行内容。
- 组件 v2 许可名单 (CTP-020)：引入了一种机制，可控制 CF 运行时的安全政策
- 通过环境路由运行程序 (CTP-021)：提议更改运行程序 功能被路由到组件内的子项和孙项 拓扑
- Realm Builder（新拓扑构建器 - CTP-033）在 SDK 中引入时： 一个库，用于在运行时创建复杂组件拓扑的测试。
- 新增 CML 功能语法 (CTP-023)：更改了功能路由的语法 （在 .CML 文件中）
- Stdio 即功能（CTP-031、RFC-69）：引入新的可路由功能 并定义了适用于 stdout、stdin 和 stderr 的 .CML 文件语法， 路由。
- 从子级使用 (CTP-036)：虽然有细微更改，但会影响约束条件 组件之间的路由
反面示例：仍然不需要 RFC 的过往更改
- Component Framework 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 流程。