RFC-0098:组件框架 RFC 标准

RFC-0098:组件框架 RFC 标准
状态已接受
领域
  • 组件框架
  • 治理
说明

RFC 流程附录,定义了组件框架的广泛影响。

作者
审核人
提交日期(年-月-日)2021-05-20
审核日期(年-月-日)2021-06-01

设计初衷

组件框架 (CF) 系统为在 Fuchsia 上运行软件奠定了基础。

因此,对组件框架的更改可能会对 Fuchsia 架构以及编写以 Fuchsia 为目标的软件的开发者产生广泛影响。

范围涵盖紫红色的 RFC 流程为做出具有广泛影响的技术决策提供了一致且透明的过程。本文档旨在提供必要的详细信息,以区分哪些 CF 更改具有足够广泛的影响,值得使用专用 RFC,哪些 CF 更改没有。

设计

需要 RFC 的更改

  • 导致公共 CF API、库和工具发生添加或修改的更改(如 Fuchsia SDK 中所公开)。例如,对 fuchsia.sys2fuchsia.componentfuchsia.session、CML、C++ 组件库等的更改。
  • 安全政策的更改,包括许可名单和功能路由。 例如,添加新的许可名单安全政策,或添加新的可路由功能。
  • 对组件管理器进行的更改会导致外部可见的影响。例如,关闭顺序的计算方式发生变化,或性能配置文件(代码大小、内存用量、CPU 时间)发生任何重大更改。
  • 对会话管理器进行更改会导致外部可见的影响。例如,从平台路由到会话的功能集发生更改(反之亦然),或者其性能概况发生任何重大更改。
  • 引入了或移除会话中所使用的平台组件的变更(作为 SDK 的一部分)。例如:引入了旨在跨会话重复使用的全新“管理器”组件。
  • 为组件管理器新增了调试或诊断功能。例如,新的日志分析功能或 Inspect 的新增功能。
  • 提出对组件架构进行修改的变更。例如,引入新的资源管理和配额概念。
  • .CML 文件语法的重大变更或新增内容。例如,更改 .CML 文件如何表达到子项的路由的结构。

当某项更改无法完全符合上述条件时,默认立场是:

1) 遵循 RFC 流程;或 1) 从 Fuchsia 工程委员会收集意见

记录现状的 RFC 是可选的,但鼓励使用。发布现状 RFC 可将对 Fuchsia 现有架构的认识扩展到更多个人,包括 Google 外部的个人。此外,它们还提供了对架构当前状态的参考,供未来的 RFC 作者链接到。

正例:过去需要 RFC 的更改

  • 组件解析器 (CTP-013):引入了 CF 扩展点,使组件作者能够更改将组件网址解析为组件元数据和可执行内容的方式。
  • 组件 v2 许可名单 (CTP-020):引入了一种机制来控制 CF 运行时的安全政策
  • 通过环境路由运行程序 (CTP-021):提出了一项更改,以更改将运行程序功能路由到组件拓扑内的子级和孙级的方式
  • Realm Builder (nee 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):提出了一种新机制,用于配置 module_manager 的内部行为,以消除通过不太高级的配置机制引入的技术债务。
  • 组件图分析 (CTP-034):在 fuchsia.git 中引入了对组件清单的构建时静态分析,以捕获因人为错误而导致路由中的不匹配问题。

从创意走向 RFC

从原型设计到从同行设计反馈,再到利用生产级质量的代码和 API 获得实际的客户体验,许多功能都需要您执行一系列相关工作。CF 贡献者获得使用功能以及以迭代方式扩大受众群体的经验并不罕见。例如,功能提案可能会经过非正式的设计流程(包括核心团队成员、实现和 fuchsia.git 开发者的实验),之后才进行更正式的 RFC 流程。

贡献者可以自行决定提前进入 RFC 流程,尤其是当他们可以根据上述标准预测其设计将用于 RFC 时。

实施策略

对于已经完成 CF 项目既定设计审核流程的任何工作,不要求追溯遵循此处定义的 RFC 标准。

如果贡献者希望与 CF 团队合作制定 RFC,可以随时与 component-framework-dev@fuchsia.dev 联系,我们会为他们分配一个指定联系人。

性能

无影响,仅处理更改。

工效学设计

如果我们发现此处所述的条件允许 RFC 流程更好地进行更改,或者发现此处所列条件的限制过于严格,我们将重新考虑这些条件。

向后兼容性

无影响。

安全注意事项

对用于修改安全政策或策略的组件框架区域的更改将需要 RFC。

隐私注意事项

对用于修改隐私权政策或策略的组件框架区域的更改将需要 RFC。

测试

无影响。

文档

不适用。

缺点、替代方案和未知情况

本文档中的标准能否在广泛、包容性审核(以速度为代价)与更有针对性的审核之间取得适当的平衡,目前还不确定。

另一种替代方案是保持现状:CF 团队使用其内部 CTP 流程。

早期技术和参考资料