| 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++ 元件程式庫等的變更。 - 安全政策變更，包括許可清單和功能路由。例如新增允許清單安全政策，或新增可路由的能力。
- Component Manager 的變更會導致外部可見的效果。例如變更關機順序的計算方式，或是對效能設定檔 (程式碼大小、記憶體用量、CPU 時間) 進行任何重大變更。
- 對工作階段管理工具所做的變更，可能會對外部產生可見的影響。例如，從平台傳送至工作階段的功能組合有所變更，反之亦然，或是其效能設定檔有任何重大變更。
- 引入或移除在工作階段中使用的平台元件的變更，屬於 SDK 的一部分。舉例來說，您可以導入新的「管理員」元件，以便在不同工作階段重複使用。
- Component Manager 的新偵錯或診斷功能。例如，新的記錄分析功能，或新增的檢查功能。
- 變更建議對元件架構進行修改。例如，引入新的資源管理和配額概念。
- .CML 檔案語法有重大變更或新增語法。例如，變更 .CML 檔案如何向子項表示路由的結構。
如果變更不完全符合上述條件，預設態度會是下列任一項：
1) 遵循 RFC 程序，或
您可以選擇是否要提供說明現況的 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 程序。