| RFC-0027：用多少付多少 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 當您將功能新增至 FIDL 時，我們應評估新增該功能對於 FIDL 使用者在未使用新功能的情況下需要支付的費用。我們應該對不會用到功能的使用者接受付費功能，有極高的標準。 |
| 作者 | |
| 提交日期 (年/月) | 2019-01-19 |
| 審查日期 (年/月) | 2019-02-04 |
摘要
本文件提出了我們在 RFC 審查程序中應套用的設計原則：
以量計價，即付即用
具體來說，在為 FIDL 新增功能時，我們應評估新增該功能對於使用 FIDL 但未使用新功能的使用者需要支付的費用。我們應該設下非常高的門檻，才能接受非使用功能所產生的費用。
提振精神
FIDL 最重要的一個面向，是 Fuchsia 全面使用 FIDL 進行處理序間通訊，因此可以定義系統 ABI。
多數處理序間通訊的用途都是效能關鍵。當使用者評估技術來處理這些攸關效能的用途時，FIDL 會與自訂訊息格式、臨時序列化和去序列化處理常式競爭。
處理序間通訊的其他用途是高度彈性的關鍵。當使用者評估技術來處理這些彈性關鍵使用情境時，FIDL 會與通訊協定緩衝區或其他網路導向訊息格式競爭。
為了能在 Fuchsia 中全面使用，FIDL 必須滿足這兩個需求。具體而言，在 FIDL 中運作的通訊協定設計人員需要在效能和彈性之間權衡取捨，才能滿足他們的需求。
採用「用多少付多少」的設計原則，讓注重效能的客戶不必為支援彈性的功能付費；如果採用雙重機制，「用多少付多少」的「用多少付多少」的計費方式，FIDL 就能服務關鍵客戶。
設計
本節說明我們如何實現這個設計原則的歷史，以及正面與負面示例。
搜尋記錄
FIDL 是 Mojo 處理序間通訊系統的革新。當時，Mojo 比 FIDL 高出許多，這對於彈性關鍵用途來說相當好用。但是，由於系統提供的靈活彈性無法滿足他們的需求，因此他們傾向對效能至關重要的客戶表示不願意採用 Mojo。
FIDL2 的原始設計 (即本寫作目前的 FIDL 版本疊代版本，約為 2017-03-01) 在設計領域中挑選了不同的點。為了贏得對效能至關重要的客戶，FIDL2 的彈性遠低於 Mojo，可讓 FIDL2 與自訂訊息格式和臨時序列化和去序列化處理常式相比，對效能較有競爭力。部分用戶端仍需要臨時序列化和去序列化處理常式，但 FIDL2 已廣泛用於訊息格式，以供處理序間通訊。
FIDL2 的原始設計已針對效能過度旋轉，需要加以改善，才能滿足使用彈性重要客戶的需求。為了成功執行，FIDL 必須新增支援用途的功能，以便提供靈活彈性，同時讓不需要彈性的客戶也能犧牲效能。
結構體和資料表
「用多少付多少」的正向例子是 RFC-0047，當中包含資料表。資料表是一種獨立資料類型，可以支援關鍵彈性用途，而不是取代結構 (其具有固定大小和版面配置，支援關鍵效能用途)。通訊協定設計人員能夠決定是否支付這項彈性的費用。
擴充工會
另一個重要的例子是 RFC-0061，其中引入了可擴充聯集。這個例子說明我們不應盲目套用這個原則。在這個設計中，您可以選擇是否要將擴充聯集做為獨立概念導入，或以可擴充的聯集取代所有非擴充的聯集。
透過這個選擇，我們可以做出價值判斷，在評估聯集所有用戶端上的效能成本，以及兩個大範圍重疊建構的複雜成本 (例如，增加通訊協定設計人員的原生負載，以針對用途選擇合適的結構)。在這個案例中，我們分析了聯集的用戶端，並認為大部分的值具有彈性，意味著大部分的 聯集用戶端可承擔彈性成本，而不會導致他們並未針對未使用的功能付費。以無法滿足彈性的用途來說，我們深知客戶需要額外成本並不會感到負擔。
導入策略
設計處理序間通訊系統的一種策略，是先找出所有問題的最佳平衡點，然後實作系統。遺憾的是，設計處理序間通訊系統時所面臨的疑慮相當複雜，此策略並不容易處理人員能力所及。反之，我們制定的策略是盡其所能做到，然後逐步修正設計，更好地滿足客戶的需求。
大體而言，在效能與彈性的顧慮中，我們有兩種策略可供使用：從著重效能或過度強調彈性，進而達到理想的平衡。
另一種解讀這份文件的方式是先提出針對 FIDL 設計的工程計畫，從著重效能 (如原始的 FIDL2 設計) 著手，然後增加彈性並維持效能，在效能與彈性之間取得平衡。
評估 FIDL 的變更以及做為 RFC 程序的一部分時，我們希望此原則應與其他設計考量事項相加。此時，有幾種方法較適合解決責任：評估對可能受影響的使用者產生的影響，然後審視先前一項技術 (例如 Protobuf 的最佳化工作，或 FlatBuffers 設計選擇)，思考哪些人員需要吸收複雜性 (例如，使用者、語言設計人員、繫結作者的影響) 是否會因此降低。我們最終必須判斷如何在這些因素之間取得平衡。
說明文件與範例
本文件建議在 FIDL 效率目標清單中加入「用多少付多少」原則。
回溯相容性
這個原則與目前的 FIDL 設計與工程計畫回溯相容。
效能
這個原則重視效能，
安全性
這個原則可能對安全性造成負面影響，因為符合原則可能會產生較複雜的系統 (例如同時包含結構體和資料表)。
缺點、替代方案和未知
本提案的一個成本，是隱藏可用於因應靈活彈性的設計空間，而這代價是攸關效能的應用情境。
另一種採用這項設計原則的成本會使得 FIDL 系統變得更複雜。舉例來說，在所有位置使用資料表，比在其他位置使用結構更容易。這會對 FIDL 實作和使用 FIDL 的開發人員造成負擔。為減少這個缺點，我們在採行這項原則時，應考量這樣的複雜成本。
另一個在效能與彈性之間取得平衡的策略，是過度強調彈性，藉此達到理想的平衡。這種做法的難處在於，人類只需添加程式碼而非移除程式碼，藉此進行工程系統，例如像黏土雕塑，而非大理石雕刻。比起透過新增程式碼來提升效能，加入程式碼是更容易增加的彈性。
先前的圖片和參考資料
許多其他語言都採用「用多少付多少」的設計原則，包括 C++1 和 Rust2。