4 ms·

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 pol

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

xyz-x 7y ago
Very nice of people to down-vote because they don't agree with what I write; I'm not being mean or evil here, I'm just stating an opinion and trying to back that opinion up with clear reasoning, references and links to actual research. Down-voting then seems very much like group-think to me. > 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. The point of my comment was exactly that there were many things in the release notes (and subsequent visits to the site) which were unclear. > As others have pointed out, you are taking a very superficial and literalist definition of OOP and FP. Precisely, which is my point; why use that terminology at all? It's neither specifically OOP nor FP, but if it's something, it's more FP than OOP to program with functions. Either way, it's super-superficial (pun intended! :)) and detracts from your message in your release notes! > `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. But my point is whether the RPC frameworks garantuees complete messages or only complete "chunks" to arrive atomically? > What is "not the case"? The whole point of this streaming feature is to do exactly what's described in your Wikipedia quote. You're not solving the problem as far as I can read in your article, you've only pointed it out. In my second link, you'll see there are both a) second-, third- etc hop buffers to take into consideration at the sending side, b) there's timing to take into consideration, c) there's the whole "send a large message initially" heuristic, to take into consideration; all in all it turns into the end-to-end argument — you need knowledge on both sides to optimise this, and preferrably an out of band channel. > "Time travel" and "infinitely faster" are obviously tongue-in-cheek claims. It's obvious the literal claims are, but it may not be obvious to readers that your trace diagram is also tounge-in-cheek; at least clearly break with the jokey-attitude afterwards and perhaps show an actual trace diagram of how it works (because the trace diagram is only partially a lie; the pipelineing is still an interesting concept that I think people want to understand!). > No, the calling thread does not block. In your sample here you block https://github.com/capnproto/capnproto/blob/master/c++/samples/calculator-client.c++#L139 https://github.com/capnproto/capnproto/blob/master/c++/sampl... to get the result. What I'm saying is that it's very unclear how you compose your flow without doing the blocking wait to get intemediate results in between RPC calls. (Exactly: you seem to lack a monadic control flow, specifically the tie-in that endofunctors would give you, and given this lack, you cannot handle exceptions out of band to the happy-path via Choice/Either/Result types) > Haha yeah that's me, just some amateur that knows nothing about network protocols... No, it's not nothing about you. I'm sure you're very competent. I'm sure Can'n'Proto is competent too; what I'm talking about is the way the framework is described and how the messaging looks to someone with close to two decades of programming experience. I hope you take is like this; as constructure criticism. I'm already very happy that you replied, because just as I believe you're a stanch proponent of your RPC framework and believe in it, I believe in my gut feeling when it comes to software — and my gut is telling me the above about your marketing message.

xyz-x 7y ago

Very nice of people to down-vote because they don't agree with what I write; I'm not being mean or evil here, I'm just stating an opinion and trying to back that opinion up with clear reasoning, references and links to actual research. Down-voting then seems very much like group-think to me. > 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. The point of my comment was exactly that there were many things in the release notes (and subsequent visits to the site) which were unclear. > As others have pointed out, you are taking a very superficial and literalist definition of OOP and FP. Precisely, which is my point; why use that terminology at all? It's neither specifically OOP nor FP, but if it's something, it's more FP than OOP to program with functions. Either way, it's super-superficial (pun intended! :)) and detracts from your message in your release notes! > `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. But my point is whether the RPC frameworks garantuees complete messages or only complete "chunks" to arrive atomically? > What is "not the case"? The whole point of this streaming feature is to do exactly what's described in your Wikipedia quote. You're not solving the problem as far as I can read in your article, you've only pointed it out. In my second link, you'll see there are both a) second-, third- etc hop buffers to take into consideration at the sending side, b) there's timing to take into consideration, c) there's the whole "send a large message initially" heuristic, to take into consideration; all in all it turns into the end-to-end argument — you need knowledge on both sides to optimise this, and preferrably an out of band channel. > "Time travel" and "infinitely faster" are obviously tongue-in-cheek claims. It's obvious the literal claims are, but it may not be obvious to readers that your trace diagram is also tounge-in-cheek; at least clearly break with the jokey-attitude afterwards and perhaps show an actual trace diagram of how it works (because the trace diagram is only partially a lie; the pipelineing is still an interesting concept that I think people want to understand!). > No, the calling thread does not block. In your sample here you block https://github.com/capnproto/capnproto/blob/master/c++/samples/calculator-client.c++#L139 https://github.com/capnproto/capnproto/blob/master/c++/sampl... to get the result. What I'm saying is that it's very unclear how you compose your flow without doing the blocking wait to get intemediate results in between RPC calls. (Exactly: you seem to lack a monadic control flow, specifically the tie-in that endofunctors would give you, and given this lack, you cannot handle exceptions out of band to the happy-path via Choice/Either/Result types) > Haha yeah that's me, just some amateur that knows nothing about network protocols... No, it's not nothing about you. I'm sure you're very competent. I'm sure Can'n'Proto is competent too; what I'm talking about is the way the framework is described and how the messaging looks to someone with close to two decades of programming experience. I hope you take is like this; as constructure criticism. I'm already very happy that you replied, because just as I believe you're a stanch proponent of your RPC framework and believe in it, I believe in my gut feeling when it comes to software — and my gut is telling me the above about your marketing message.