Cap'n Proto 0.8: Streaming flow control, HTTP-over-RPC, fibers
For me, new to cap&#x27;n&#x27;proto, this blog post doesn&#x27;t cut the mustard because of multiple red flags:<p>- to start, it&#x27;s self-congratulatory at stating that streaming already exists &quot;[via] promise pipelining&quot; — but that has a name, it&#x27;s called polling, not streaming. Making asynchronicity explicit doesn&#x27;t make a protocol streaming.<p>- in the same paragraph an &quot;object-capability model&quot; is introduced as a concept, but not explained<p>- second paragraph: &quot;think of this like providing a callback function in an object-oriented language&quot;, when it should be &quot;in a functional programming language&quot; (callbacks aren&#x27;t OOP, they are per definition functional programming)<p>- second paragraph, vocab: what&#x27;s a &quot;temporary RPC object&quot;? Contrary to the precise, albeit unexplained vocabulary, in the first pragraph, this is vague.<p>- creating examples with &quot;MyInterface&quot; being the service shows a lack of creativity and a rather low ability to communicate; is this service on the server side, or the client side? Noone knows, and &quot;Callback&quot; is not a good name for a callback, it should be &quot;SendEmailWithData&quot; or something that makes sense.<p>- `sendChunk @0 (chunk :Data)` doesn&#x27;t make sense to a beginner without explaination; what&#x27;s `@0` and why do I care?<p>Here&#x27;s what made me write this comment despite the threshold annoyance in commenting:<p>- Why name a <i>message</i>, `Data` when it&#x27;s clearly NOT a chunk of data in layer-3&#x2F;layer-4, but rather a layer-7 artifact with retries and checksumming implemented to ensure complete and accurate message delivery?<p>Finally, the articles goes on and discusses control flow via a proxy variable; your OS&#x27;es TCP send buffer size. But the linked Wikipedia article states:<p>&gt; because the protocol can only achieve optimum throughput if a sender sends a sufficiently large quantity of data before being required to stop and wait until a confirming message is received from the receiver, acknowledging successful receipt of that data<p>Which is not the case for Cap&#x27;n&#x27;Proto (admittedly it states it uses a hack). And there&#x27;s no discussion of end-to-end problems like BufferBloat, which are very hard to solve by only looking at your own buffer <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Bufferbloat#Solutions_and_mitigations" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Bufferbloat#Solutions_and_miti...</a> — or even the semantics of &quot;blocking on server&#x27;s return value&quot; (Is it enough for the receiving process to have the message in memory? The type system showcased seems to tell that story)<p>The article also doesn&#x27;t state how a simple RPC call works. Going to <a href="https:&#x2F;&#x2F;capnproto.org&#x2F;rpc.html" rel="nofollow">https:&#x2F;&#x2F;capnproto.org&#x2F;rpc.html</a> immediately puts me off by inventing &quot;time travel&quot;, calling it &quot;promise pipelining&quot; and showing an impossible trace diagram (you can&#x27;t have messages go backwards in time).<p>But when explaining it, it&#x27;s really RPC message coalescing and compile-time reference indirection, from the promise to the underlying object instance as it is after executing the coalesced message pipeline. However, even when using the example of a file system (which is about as exception-intense as you can imagine), exceptions are ignored.<p>Looking through the Calculator example (<a href="https:&#x2F;&#x2F;github.com&#x2F;capnproto&#x2F;capnproto&#x2F;blob&#x2F;master&#x2F;c++&#x2F;samples&#x2F;calculator-client.c++" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;capnproto&#x2F;capnproto&#x2F;blob&#x2F;master&#x2F;c++&#x2F;sampl...</a>) it turns out they haven&#x27;t actually performed the compile-time indirection, but actually block the calling thread like any random do-it-yourself-RPC framework out there.<p>What a RPC framework should do is give you:<p>- an extremely clear serialisation model that is outside of the framework<p>- a clear API<p>- clear garantuees &#x2F; invariants on how it manages the complexities of network programming<p>In short: it must be very clear in what it promises. Cap&#x27;n&#x27;proto is not.