3 ms·

That's the kind of code that would be used in a typical RPC system written in the last ~20 years. You have some sort of client stub, a request object, and a res

That's the kind of code that would be used in a typical RPC system written in the last ~20 years. You have some sort of client stub, a request object, and a response handle that has operations for waiting until the server has generated the response. The actual marshaling implementation could be ASN.1 or JSON or Thrift or whatever the local programmers want. I want to know how the Cap'n'proto design discussed in the post is significantly different from this standard RPC model.

philjohn 13y ago
If you're executing a 2nd procedure call that uses the output of the first (or 3rd, 4th 5th etc) then it requires 1 call. A traditional RPC system would either need a combined method (which is suboptimal from a "clean design" perspective) or you'd get the response of the 1st back, and then just pass it back to the server for the 2nd call.
- jmillikin 13y ago
  So the major improvement described here is a hint to the server that it should pass the response from one RPC directly into the request of another, rather than returning anything to the client? That seems like it'd only be useful in very specific circumstances; you'd need RPC methods with the same type for request and response, and it only works if you're using the same backend for each call (e.g. you can't have load balancing of separate calls).
  - kentonv 13y ago
    If you read the documentation, I give an extended argument for why this is useful: it enables more object-oriented protocol design. http://kentonv.github.io/capnproto/rpc.html http://kentonv.github.io/capnproto/rpc.html Also, it is not the case that the new RPC's input type has to match the old one's output. You can take just one object embedded in the old response and use it in the new request. Please do look at the examples.
kentonv 13y ago
Cap'n Proto's RPC interface is different. The call returns a promise (like a future), but you don't have to wait on it. The promise itself has methods that let you do things with the results, such as call them or use them in the parameters to other calls that go back to the server. These chained calls can be sent to the server before the initial call completes, by just telling the server "When the previous call completes, do this with the result". This is all described in detail in the docs. http://kentonv.github.io/capnproto/rpc.html http://kentonv.github.io/capnproto/rpc.html

philjohn 13y ago

If you're executing a 2nd procedure call that uses the output of the first (or 3rd, 4th 5th etc) then it requires 1 call. A traditional RPC system would either need a combined method (which is suboptimal from a "clean design" perspective) or you'd get the response of the 1st back, and then just pass it back to the server for the 2nd call.

jmillikin 13y ago
So the major improvement described here is a hint to the server that it should pass the response from one RPC directly into the request of another, rather than returning anything to the client? That seems like it'd only be useful in very specific circumstances; you'd need RPC methods with the same type for request and response, and it only works if you're using the same backend for each call (e.g. you can't have load balancing of separate calls).
- kentonv 13y ago
  If you read the documentation, I give an extended argument for why this is useful: it enables more object-oriented protocol design. http://kentonv.github.io/capnproto/rpc.html http://kentonv.github.io/capnproto/rpc.html Also, it is not the case that the new RPC's input type has to match the old one's output. You can take just one object embedded in the old response and use it in the new request. Please do look at the examples.

kentonv 13y ago

Cap'n Proto's RPC interface is different. The call returns a promise (like a future), but you don't have to wait on it. The promise itself has methods that let you do things with the results, such as call them or use them in the parameters to other calls that go back to the server. These chained calls can be sent to the server before the initial call completes, by just telling the server "When the previous call completes, do this with the result". This is all described in detail in the docs. http://kentonv.github.io/capnproto/rpc.html http://kentonv.github.io/capnproto/rpc.html