Wow ok... lots of incorrect assumptions here. Just for fun let's address some of them.

> but that has a name, it's called polling, not streaming.

It's not polling. The idea is that the callback is called multiple times to send all the chunks, for one invocation of `streamingCall()`. Sorry if that wasn't clear.

BTW, Promise Pipelining is only involved in the client -> server streaming example.

> - in the same paragraph an "object-capability model" is introduced as a concept, but not explained

> - `sendChunk @0 (chunk :Data)` doesn't make sense to a beginner without explaination; what's `@0` and why do I care?

> - second paragraph, vocab: what's a "temporary RPC object"? Contrary to the precise, albeit unexplained vocabulary, in the first pragraph, this is vague.

This is a news post about a new release of an existing tool. You're expected to be familiar with the tool already, or if you are not, you can go read the rest of the web site to learn about it.

> - second paragraph: "think of this like providing a callback function in an object-oriented language", when it should be "in a functional programming language" (callbacks aren't OOP, they are per definition functional programming)

As others have pointed out, you are taking a very superficial and literalist definition of OOP and FP. That said, I should have said "callback object", because that's what the example actually illustrates.

> is this service on the server side, or the client side?

Cap'n Proto is a peer-to-peer protocol, not a client-server protocol. Either side can export interfaces and either side can initiate calls.

> - Why name a message, `Data` when it's clearly NOT a chunk of data in layer-3/layer-4, but rather a layer-7 artifact with retries and checksumming implemented to ensure complete and accurate message delivery?

`Data` is a basic data type in Cap'n Proto. It means an array of bytes. You can use any other type here if you want, it's just an example.

> > 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

> Which is not the case for Cap'n'Proto

What is "not the case"? The whole point of this streaming feature is to do exactly what's described in your Wikipedia quote.

> And there's no discussion of end-to-end problems like BufferBloat

BufferBloat is mentioned several times in the post (though I called it "queuing latency", describing the symptom rather than the cause).

> Going to https://capnproto.org/rpc.html immediately puts me off by inventing "time travel", calling it "promise pipelining" and showing an impossible trace diagram (you can't have messages go backwards in time).

"Time travel" and "infinitely faster" are obviously tongue-in-cheek claims.

> However, even when using the example of a file system (which is about as exception-intense as you can imagine), exceptions are ignored.

They are not ignored. Exceptions propagate to dependent calls. So if you send a chain of pipelined calls and the first call throws, all the later calls resolve by throwing the same exception. Eventually the caller waits for something and discovers the exception.

> it turns out they haven't actually performed the compile-time indirection, but actually block the calling thread

No, the calling thread does not block.

> like any random do-it-yourself-RPC framework out there.

Haha yeah that's me, just some amateur that knows nothing about network protocols...