Cap'n Proto 是一種速度極快的數(shù)據(jù)交換格式和 capability-based RPC 系統(tǒng)，于 2013 年 4 月開源發(fā)布。時至今日，Cap'n Proto 1.0 終于

目前他已離開谷歌，因此 “Cap'n Proto 不隸屬于谷歌，也從未隸屬于谷歌”?；鶞蕼y試結(jié)果表明，Cap'n Proto 比 Protocol Buffers 快無限倍。

自上一個版本 v0.10 以來，新版本的一些亮點內(nèi)容包括：

• 針對 Cap'n Proto RPC 性能的一系列優(yōu)化。其中包括減少 RPC 實現(xiàn)和 KJ I/O 框架的內(nèi)存分配量，增加從 RPC 協(xié)議中省略某些信息以減少流量的功能，以及更好地緩沖一起發(fā)送和接收的小信息以減少系統(tǒng)調(diào)用。
• Breaking change： 在此之前，服務(wù)器可在調(diào)用完成后調(diào)用 context.allowCancellation ()，選擇允許取消 RPC。在 1.0 版中，選擇取消 RPC 可通過模式注解（c++.capnp 中定義的 allowCancellation 注解）來實現(xiàn)；模式級注解可以一次對整個文件進行設(shè)置。此外，動態(tài)選擇加入需要大量的簿記工作，在實際使用中會對性能產(chǎn)生明顯影響；而改用注釋則能提高性能。對于從未使用 context.allowCancellation () 的用戶來說，升級到 1.0 版時無需做任何更改，默認情況下仍不允許取消。(如果受到影響，你將看到編譯錯誤。如果沒有編譯錯誤，則無需擔(dān)心）。
• KJ 現(xiàn)在在有 kqueue () 的系統(tǒng)（MacOS 和 BSD 衍生版本）上使用它來處理異步 I/O。在 Linux 上，KJ 一直使用 epoll，但在其他類 Unix 平臺上，KJ 一直使用較慢的 poll ()-based 方法。
• KJ 的 HTTP 客戶端和服務(wù)器實現(xiàn)現(xiàn)在支持 CONNECT 方法。
• 引入了一個新類 capnp::RevocableServer，以幫助在生命周期不受包裝器控制的對象周圍導(dǎo)出 RPC 包裝器。
• 以及一些更小的 bug 修復(fù)和改進。詳情可參閱 PR 歷史記錄。

在 1.0 版本發(fā)布后，2.0 版本的工作也開始提上日程。根據(jù)規(guī)劃，v2.0 旨在對 Cap'n Proto 的 C++ API 及其配套的 KJ C++ 工具包庫做出一些改變；以及做一些全面的向后兼容改動以修復(fù)一些問題，并改善團隊中開發(fā)人員的體驗。目前的一些想法包括：

• 需要一個支持 C++20 甚至 C++23 的編譯器。Cap'n Proto 1.0 僅需要 C++14。
• 需要一個支持 C++20 協(xié)程的編譯器。
• Cap'n Proto 的 RPC 應(yīng)用程序接口、KJ 的 HTTP 應(yīng)用程序接口和其他程序接口很可能會進行修改，使其更加的 coroutine-friendly。
• kj::Maybe 將變得更符合人體工學(xué)。它將不再重載 nullptr 來表示值的缺失，將引入 kj::none 來代替。KJ_IF_MAYBE 將不再生成指針，而是一個引用（這是利用 C++17 特性實現(xiàn)的一種技巧）。
• 將放棄對禁用異常情況下的編譯的支持。
• 將放棄對 no-RTTI 模式和其他會造成維護負擔(dān)的特殊模式的支持。
• 可能會修改 KJ 的引用計數(shù)方法，因為目前的設(shè)計已被證明對許多用戶來說并不直觀。
• 將修復(fù) kj::AsyncOutputStream 中一個長期存在的設(shè)計缺陷，目前 EOF 信號是通過銷毀流來發(fā)出的。取而代之的是將添加一個返回 Promise 的顯式 end () 方法。在不調(diào)用 end () 的情況下銷毀數(shù)據(jù)流將發(fā)出錯誤的斷開信號。(還想對 KJ 流 API 進行其他一些美觀改進）。
• 重新設(shè)計幾個核心 I/O API，以便更好地適應(yīng) Linux 新的 io_uring 事件通知范式。
• RPC 實現(xiàn)可能會改為默認允許取消。

值得注意的是，目前還沒有計劃對序列化格式或 RPC 協(xié)議進行任何向后不兼容的更改。所討論的更改僅影響 C++ API。用其他語言編寫的應(yīng)用程序完全不受這一切的影響。

正式的 2.0 版本短時間內(nèi)不會推出發(fā)布，或許也要等上幾年。