| RFC-0098: Component Framework RFC Criteria | |
|---|---|
| Status | Accepted |
| Areas |
|
| Description | An addendum to the RFC process that defines broad impact for Component Framework. |
| Authors | |
| Reviewers | |
| Date submitted (year-month-day) | 2021-05-20 |
| Date reviewed (year-month-day) | 2021-06-01 |
Motivation
The Component Framework (CF) system provides the foundations for running software on Fuchsia. With the exception of a few early-boot processes, all software spanning from low-level system services to UI-driven front end apps, are components and operate in the context of the Component Runtime.
For this reason, changes to the Component Framework can have a broad impact on the Fuchsia architecture and on developers who write software targeting Fuchsia.
The Fuchsia-wide RFC process provides a consistent and transparent process for making technical decisions with broad impact. This document seeks to provide the detail necessary to disambiguate between which CF changes have sufficiently broad impact to deserve a dedicated RFC, and which do not.
Design
Changes that require an RFC
- Changes resulting in additions or modifications to the public CF APIs,
libraries, and tools, as exposed in the Fuchsia SDK. For example, changes to
fuchsia.sys2,fuchsia.component,fuchsia.session, CML, C++ component libraries, and so on. - Changes to security policy, including allowlists and capability routing. For example, adding a new allowlisting security policy, or adding a new routable capability.
- Changes to Component Manager that would result in externally visible effects. For example, a change in how shutdown order is calculated, or any substantial change to its performance profile (code size, memory use, cpu time).
- Changes to Session Manager that would result in externally visible effects. For example, changes to the set of capabilities routed from the platform to sessions, and vice versa, or any substantial change to its performance profile.
- Changes that introduce or remove platform components used in sessions, as part of the SDK. For example: introducing a new "manager" component that is intended to be reused across sessions.
- New debugging or diagnostics features for Component Manager. For example, a new logs analysis feature, or additions to Inspect.
- Changes that propose modifications to the component architecture. For example, introducing new resource management and quota concepts.
- Major changes or additions to .CML file syntax. For example, changing the structure of how .CML files express routing to children.
When a change does not fit the above criteria perfectly, the default stance is to either:
1) Follow the RFC process, or 1) Seek input from the Fuchsia Engineering Council
RFCs that document the status-quo are optional but encouraged. Publishing a status-quo RFC expands awareness of the existing architecture of Fuchsia to many more individuals, including those individuals outside Google. Additionally, they provide references to the current state of the architecture for future RFC authors to link to.
Positive examples: past changes that would now require an RFC
- Component resolvers (CTP-013): introduced a CF extension point allowing component authors to alter how component URLs are resolved into component metadata and executable content.
- Components v2 allow-lists (CTP-020): introduced a mechanism to control the security policy of the CF runtime
- Route runners through environments (CTP-021): proposed a change to how runner capabilities were routed to children and grandchildren within a component topology
- Realm Builder (nee Topology Builder - CTP-033), when introduced to the SDK: a library for tests to create complex component topologies at runtime.
- New CML capability syntax (CTP-023): changed the syntax of capability routing in .CML files
- Stdio as a capability (CTP-031, RFC-69): Introduced new routable capabilities for stdout, stdin, and stderr, and defined the .CML file syntax for said routing.
- Use from child (CTP-036): although a small change, it impacts constraints previously placed on routing between components.
Negative examples: past changes that still would not require an RFC
- Component Framework API revisions (CTP-030): API revisions for better readability, and clearer semantics, without altering the behavior of the component runtime itself.
- Component Manager configurability (CTP-024): proposed a new mechanism to configure the internal behavior of component_manager to remove tech debt introduced through a less advanced configuration mechanism.
- Component Graph Analysis (CTP-034): introduced build-time static analysis on component manifests in fuchsia.git in order to catch mismatches in routing due to human error.
Progressing from idea to RFC
Many features require work along spectrum from prototyping, to design feedback
from peers, to getting hands-on customer experience with production-quality
code and APIs. It is not unusual for CF contributors to gain experience with
features, with iteratively-expanding audiences. For example, a feature proposal
may go through a less-formal design process including members of the core team,
an implementation, and then experimentation with fuchsia.git developers,
before going through the more
formal RFC process.
Contributors may opt to enter the RFC process earlier, at their discretion, especially when they can predict that their design is destined for an RFC based on the criteria described above.
Implementation strategy
Any work that has already gone through the CF project's established design review processes will not be retroactively required to adhere to the RFC criteria defined here.
If a contributor wishes to work with the CF team on an RFC, they should feel free to reach out to component-framework-dev@fuchsia.dev and we'll assign them a designated contact.
Performance
No impact, process-only change.
Ergonomics
We'll revisit these criteria if we find that the criteria herein are allowing changes to move ahead that would have been served better by the RFC process, or if the criteria herein are found to be too restrictive.
Backwards Compatibility
No impact.
Security Considerations
Changes to the Component Framework area that modify security policy or strategy will require an RFC.
Privacy considerations
Changes to the Component Framework area that modify privacy policy or strategy will require an RFC.
Testing
No impact.
Documentation
Does not apply.
Drawbacks, alternatives, and unknowns
It is unknown if the criteria in this document strike the right balance between broad, inclusive review at the expense of velocity, versus more targeted review.
Another alternative is to stick with the status-quo: the CF team uses its internal CTP process.