| 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 能夠與自訂訊息格式和臨時序列化和反序列化例程，一同提供具競爭力的效能。部分用戶端仍需要臨時序列化和反序列化例程，但 FIDL2 已成功廣泛用於處理進程間通訊的訊息格式。
FIDL2 的原始設計過度偏重效能，因此需要改良，以滿足需要彈性功能的客戶需求。為了成功，FIDL 需要新增功能，以便支援靈活的用途，同時不影響效能，以便不需靈活性的客戶也能使用。
結構體和表格
以「您只需為實際使用的資源付費」為例，RFC-0047 就屬於這類資源，因為這項資源引進了表格。資料表是獨立的資料類型，可支援需要彈性的重要用途，而非取代結構體 (具有固定大小和版面配置，可支援效能至關重要的用途)。通訊協定設計人員可以選擇是否要為這項彈性功能付費。
可擴充的聯合
另一個重要的例子是 RFC-0061，它引入了可擴充的聯集。這個例子說明我們不應盲目套用原則。在該設計中，您可以選擇是否要將可擴充的聯集做為獨立概念引入，或是是否要將所有不可擴充的聯集替換為可擴充的聯集。
這個選擇歸結於做出價值判斷，權衡對所有聯集用戶強制實施彈性所需的效能成本，以及擁有兩個重疊程度極高的結構所需的複雜度成本 (例如，對通訊協定設計人員強加認知負載，讓他們為其用途選擇正確的結構)。在本案例中，我們分析了聯盟客戶，並判斷絕大多數客戶都重視彈性，也就是說，對絕大多數聯盟客戶收取彈性費用，不會導致他們為不使用的功能付費。對於不重視彈性功能的少數使用者，我們與客戶進行諮詢，並同意額外費用不會造成負擔。
導入策略
設計進程間通訊系統的其中一個策略，就是先找出所有疑慮的理想平衡點，然後再實作系統。不幸的是，設計進程間通訊系統的相關考量相當複雜，因此這項策略超出人類能力範圍。我們採取的策略是盡可能在現階段提供最佳服務，然後透過迭代方式改善設計，以便更妥善地滿足客戶需求。
一般來說，我們可以使用兩種策略來平衡效能和彈性之間的考量：我們可以透過過度強調效能或過度強調彈性，來達到理想的平衡。
另一種解讀這份文件的方式是，建議我們為 FIDL 建構工程計畫時，一開始就過度強調效能 (如同原始 FIDL2 設計)，然後在保有效能的前提下增加彈性，以便在效能和彈性之間取得平衡。
在評估 FIDL 的變更時，我們會將這項原則與其他設計考量加以比較，這也是 RFC 程序的一部分。當兩項原則相互牴觸時，您可以採用多種方法解決這個問題：評估對可能受影響的使用者造成的影響、查看先前技術 (例如 Protobuf 的最佳化工作，或 FlatBuffers 設計選項)、思考誰需要吸收複雜度 (例如使用者、語言設計人員、繫結作者)，以及考量設計是否會對理論上的最大效能設限 (即使目前的實作方式未達到這個程度)。最終，我們必須根據自身判斷，決定如何平衡這些因素。
說明文件和範例
本文件建議將「只需為所用付費」原則加入 FIDL 效率目標清單。
回溯相容性
這項原則與目前的 FIDL 設計和工程計畫相容。
成效
這項原則重視效能。
安全性
這項原則可能會對安全性造成負面影響，因為滿足這項原則可能會導致更複雜的系統 (例如同時具有結構體和資料表)。
缺點、替代方案和未知事項
這項提案的其中一個成本，就是為了滿足需要高度彈性的用途，而犧牲需要高度效能的用途，因此會排除可用於滿足這類用途的設計空間。
採用這項設計原則的另一個成本是，會導致 FIDL 系統比原本更複雜。舉例來說，在所有地方使用表格可能比在某些地方使用結構體，以及在其他地方使用表格更簡單。這項額外的複雜性對 FIDL 實作和使用 FIDL 的開發人員來說都是負擔。為減輕這項缺點，我們在套用這項原則時，應考慮這項複雜性成本。
另一種平衡效能和彈性考量的做法，就是過度強調彈性，以便達到理想的平衡。這種做法的問題在於，人類是透過新增程式碼，而非移除程式碼來設計系統 (例如用黏土雕塑，而非用大理石雕塑)。新增程式碼可增加彈性，但新增程式碼無法提升效能。
既有技術與參考資料
許多其他語言也採用「只需依實際用量付費」的設計原則，包括 C++1 和 Rust2。