| RFC-0027：用多少付多少 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 為 FIDL 新增功能時，我們應評估新增功能對 FIDL 使用者造成的成本，即使他們不使用新功能也一樣。因此，如果某項功能會對未使用該功能的使用者造成負擔，我們就應嚴格把關，確保該功能符合接受標準。 |
| 作者 | |
| 提交日期 (年-月-日) | 2019-01-19 |
| 審查日期 (年-月-日) | 2019-02-04 |
摘要
本文提出一項設計原則，建議在 RFC 審查程序中套用：
用多少付多少
具體來說，在 FIDL 中新增功能時，我們應評估新增該功能對 FIDL 使用者造成的成本，但這些使用者不會使用新功能。因此，如果某項功能會對未使用該功能的人造成負擔，我們就應嚴格把關，不輕易接受。
提振精神
FIDL 最重要的層面之一，就是 Fuchsia 廣泛使用 FIDL 進行處理序間通訊，因此也用於定義系統 ABI。
許多程序間通訊的應用情境都對效能要求極高。當人們評估這些效能關鍵用途的技術時，FIDL 會與自訂訊息格式和隨選序列化/還原序列化常式競爭。
其他需要進程間通訊的用途，則對彈性要求較高。當人們評估這些對彈性要求極高的用途時，FIDL 會與 protobuf 或其他許多以網路為導向的訊息格式競爭。
為了在整個 Fuchsia 中廣泛使用，FIDL 必須同時滿足這兩項需求。具體來說，使用 FIDL 的通訊協定設計人員需要能夠在效能和彈性之間取捨，以滿足自身需求。
採用「用多少付多少」的設計原則，可讓重視效能的客戶避免為支援彈性的功能付費，而「用多少付多少」的雙重原則，則可讓 FIDL 服務重視彈性的客戶。
設計
本節將說明我們如何得出這項設計原則，以及正面和負面範例。
記錄
FIDL 是 Mojo 跨程序通訊系統的演進版本。當時，Mojo 比 FIDL 靈活許多，非常適合需要高度靈活性的用途。不過，對於需要高度效能的用途，客戶不願採用 Mojo，因為系統提供的彈性無法滿足他們的需求。
FIDL2 的原始設計 (截至 2017 年 3 月 1 日，FIDL 的目前版本疊代) 在設計空間中選擇了不同的點。為了爭取對效能要求嚴格的客戶，FIDL2 的彈性遠不如 Mojo，因此 FIDL2 可透過自訂訊息格式和臨時序列化/還原序列化常式，在效能方面與 Mojo 一較高下。部分用戶仍要求使用臨時序列化和還原序列化常式，但 FIDL2 已成功廣泛用於跨程序通訊的訊息格式。
FIDL2 的原始設計過度著重效能，因此需要改良，才能滿足對彈性有高度需求的客戶。為求成功，FIDL 必須新增功能，支援彈性使用案例，同時兼顧不需要彈性的客戶效能。
結構體和資料表
「用多少付多少」的正面例子是 RFC-0047，其中導入了表格。資料表並非取代結構體 (結構體的大小和版面配置固定，支援效能關鍵用途)，而是獨立的資料型別，支援彈性關鍵用途。通訊協定設計人員可以選擇是否要支付這項彈性費用。
可擴充的聯集
另一個重要範例是 RFC-0061，其中介紹了可擴充的聯集。這個例子說明我們不應盲目套用原則。在該設計中，您可以選擇是否要將可擴充的聯集做為獨立概念導入，或是以可擴充的聯集取代所有不可擴充的聯集。
這項選擇歸結為價值判斷，也就是權衡對所有聯盟用戶強制實施彈性的效能成本，以及擁有兩個大致重疊的建構體 (例如，對通訊協定設計人員施加認知負荷，以便為其用途選擇正確的建構體) 的複雜度成本。在本案例中，我們分析了聯集用戶端，並判斷絕大多數用戶端重視彈性，這表示對絕大多數聯集用戶端收取彈性費用，不會導致他們為未使用的功能付費。對於少數不重視彈性的用途，我們與客戶諮詢後一致認為，額外費用不會造成負擔。
導入策略
設計程序間通訊系統的策略之一，是預先找出所有問題的理想平衡點，然後實作系統。很遺憾，設計程序間通訊系統的相關考量相當複雜，這種策略超出人類能力範圍。我們採取的策略是盡可能完善目前的設計，然後逐步改良，以更符合顧客需求。
一般來說，我們可以採用兩種策略，在成效和彈性之間取得平衡：從過度強調成效或過度強調彈性的角度，找出理想的平衡點。
解讀這份文件的另一種方式是，建議我們為 FIDL 規劃工程計畫時，一開始應過度強調效能 (如原始 FIDL2 設計)，然後在效能維持不變的情況下，加入彈性，以達到效能和彈性之間的平衡。
在評估 FIDL 的變更時，我們預期這項原則會與其他設計考量因素相互權衡，並納入 RFC 程序。如果兩項原則互相衝突，可以採取多種方法解決僵局：評估對可能受影響使用者的影響、參考先前技術 (例如 Protobuf 的最佳化工作或 FlatBuffers 的設計選擇)、考量誰需要吸收複雜性 (例如使用者、語言設計人員、繫結作者)，以及考量設計是否會限制理論上的最高效能 (即使目前的實作方式未達到該效能)。最終，我們需要判斷如何妥善平衡這些因素。
說明文件和範例
這份文件建議在 FIDL 的效率目標清單中，加入「只為實際用量付費」原則。
回溯相容性
這項原則與目前的 FIDL 設計和工程計畫回溯相容。
效能
這項原則重視效能。
安全性
這項原則可能會對安全性造成負面影響，因為滿足這項原則可能會導致系統更加複雜 (例如同時具有結構體和表格)。
缺點、替代方案和未知事項
這項提案的代價之一，是犧牲效能關鍵用途，以滿足彈性關鍵用途，從而限制設計空間。
採用這項設計原則的另一個代價，是 FIDL 系統會比原本更加複雜。舉例來說，在所有地方使用表格，可能比在某些地方使用結構體，在其他地方使用表格簡單。這項額外複雜度會增加 FIDL 實作的負擔，也會對使用 FIDL 的開發人員造成影響。為減輕這項缺點，我們在套用原則時應考慮這項複雜度成本。
另一種兼顧效能和彈性的策略，是過度強調彈性，以達到理想的平衡。這種做法的困難之處在於，人類是透過新增程式碼來設計系統，而不是移除程式碼 (例如，類似於用黏土雕塑，而不是用大理石雕塑)。新增程式碼來增加彈性，比新增程式碼來提升效能更容易。