| RFC-0098：元件架構 RFC 條件 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | RFC 程序的附錄，定義元件架構的廣泛影響。 |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2021-05-20 |
| 審查日期 (年-月-日) | 2021-06-01 |
提振精神
元件架構 (CF) 系統提供在 Fuchsia 上執行軟體的基礎。除了少數早期啟動程序外，從低階系統服務到 UI 驅動的前端應用程式，所有軟體都是元件，並在元件執行階段的環境中運作。
因此，元件架構的變更可能會對 Fuchsia 架構造成廣泛影響，也會影響編寫以 Fuchsia 為目標的軟體開發人員。
Fuchsia 全面 RFC 程序提供一致且透明的程序，可做出影響廣泛的技術決策。本文旨在提供必要詳細資料，協助您區分哪些 CF 變更的影響範圍夠廣，值得專門發布 RFC，哪些則否。
設計
需要 RFC 的變更
- 導致 Fuchsia SDK 中公開 CF API、程式庫和工具新增或修改的變更。例如
fuchsia.sys2、fuchsia.component、fuchsia.session、CML、C++ 元件程式庫等。 - 安全政策異動，包括許可清單和功能轉送。 例如新增允許清單安全政策，或新增可路由傳輸的能力。
- 元件管理服務的變更會導致外部可見的影響。舉例來說，如果關機順序的計算方式有所變更，或是效能設定檔 (程式碼大小、記憶體用量、CPU 時間) 有任何重大變更，
- 工作階段管理員的變更會導致外部可見的影響。舉例來說，從平台路由至工作階段的功能集發生變更，反之亦然，或是效能設定檔有任何重大變更。
- 導入或移除工作階段中使用的平台元件，做為 SDK 的一部分。舉例來說，您可以導入新的「管理員」元件，以便在不同工作階段中重複使用。
- 元件管理工具的新偵錯或診斷功能。例如，新增記錄分析功能，或擴充「檢查」功能。
- 提議修改元件架構的變更。例如，導入新的資源管理和配額概念。
- .CML 檔案語法有重大變更或新增內容。例如，變更 .CML 檔案向子項表示路徑的結構。
如果變更不完全符合上述條件，預設立場是：
1) 遵循 RFC 程序，或 1) 徵詢 Fuchsia 工程委員會的意見
記錄現狀的 RFC 為選用項目，但建議使用。發布現狀 RFC 可讓更多人 (包括 Google 以外的人) 瞭解 Fuchsia 的現有架構。此外，這些文件也提供架構現況的參考資料，供日後的 RFC 作者連結。
正面範例：過去的變更現在需要 RFC
- 元件解析器 (CTP-013)：導入 CF 擴充點，讓元件作者能變更元件網址解析為元件中繼資料和可執行內容的方式。
- Components 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 程序。