cannam@62: ---
cannam@62: layout: post
cannam@62: title: "Cap'n Proto v0.4: Time Traveling RPC"
cannam@62: author: kentonv
cannam@62: ---
cannam@62: 
cannam@62: Well, [Hofstadter](http://en.wikipedia.org/wiki/Hofstadter's_law) kicked in and this release took
cannam@62: way too long.  But, after three long months, I'm happy to announce:
cannam@62: 
cannam@62: ### Time-Traveling RPC _(Promise Pipelining)_
cannam@62: 
cannam@62: <img src='{{ site.baseurl }}images/time-travel.png' style='max-width:639px'>
cannam@62: 
cannam@62: v0.4 finally introduces the long-promised [RPC system]({{ site.baseurl }}rpc.html).  Traditionally,
cannam@62: RPC is plagued by the fact that networks have latency, and pretending that latency doesn't exist by
cannam@62: hiding it behind what looks like a normal function call only makes the problem worse.
cannam@62: Cap'n Proto has a simple solution to this problem:  send call results _back in time_, so they
cannam@62: arrive at the client at the point in time when the call was originally made!
cannam@62: 
cannam@62: Curious how Cap'n Proto bypasses the laws of physics?
cannam@62: [Check out the docs!]({{ site.baseurl }}rpc.html)
cannam@62: 
cannam@62: _UPDATE:  There has been some confusion about what I'm claiming.  I am NOT saying that using
cannam@62: promises alone (i.e. being asynchronous) constitutes "time travel".  Cap'n Proto implements a
cannam@62: technique called Promise Pipelining which allows a new request to be formed based on the content
cannam@62: of a previous result (in part or in whole) before that previous result is returned.  Notice in the
cannam@62: diagram that the result of foo() is being passed to bar().  Please
cannam@62: [see the docs]({{ site.baseurl }}rpc.html) or
cannam@62: [check out the calculator example](https://github.com/kentonv/capnproto/blob/master/c++/samples)
cannam@62: for more._
cannam@62: 
cannam@62: ### Promises in C++
cannam@62: 
cannam@62: _UPDATE:  More confusion.  This section is **not** about pipelining ("time travel").  This section
cannam@62: is just talking about implementing a promise API in C++.  Pipelining is another feature on top of
cannam@62: that.  Please [see the RPC page]({{ site.baseurl }}rpc.html) if you want to know more about
cannam@62: pipelining._
cannam@62: 
cannam@62: If you do a lot of serious Javascript programming, you've probably heard of
cannam@62: [Promises/A+](http://promisesaplus.com/) and similar proposals.  Cap'n Proto RPC introduces a
cannam@62: similar construct in C++.  In fact, the API is nearly identical, and its semantics are nearly
cannam@62: identical.  Compare with
cannam@62: [Domenic Denicola's Javascript example](http://domenic.me/2012/10/14/youre-missing-the-point-of-promises/):
cannam@62: 
cannam@62: {% highlight c++ %}
cannam@62: // C++ version of Domenic's Javascript promises example.
cannam@62: getTweetsFor("domenic") // returns a promise
cannam@62:   .then([](vector<Tweet> tweets) {
cannam@62:     auto shortUrls = parseTweetsForUrls(tweets);
cannam@62:     auto mostRecentShortUrl = shortUrls[0];
cannam@62:     // expandUrlUsingTwitterApi returns a promise
cannam@62:     return expandUrlUsingTwitterApi(mostRecentShortUrl);
cannam@62:   })
cannam@62:   .then(httpGet) // promise-returning function
cannam@62:   .then(
cannam@62:     [](string responseBody) {
cannam@62:       cout << "Most recent link text:" << responseBody << endl;
cannam@62:     },
cannam@62:     [](kj::Exception&& error) {
cannam@62:       cerr << "Error with the twitterverse:" << error << endl;
cannam@62:     }
cannam@62:   );
cannam@62: {% endhighlight %}
cannam@62: 
cannam@62: This is C++, but it is no more lines -- nor otherwise more complex -- than the equivalent
cannam@62: Javascript.  We're doing several I/O operations, we're doing them asynchronously, and we don't
cannam@62: have a huge unreadable mess of callback functions.  Promises are based on event loop concurrency,
cannam@62: which means you can perform concurrent operations with shared state without worrying about mutex
cannam@62: locking -- i.e., the Javascript model.  (Of course, if you really want threads, you can run
cannam@62: multiple event loops in multiple threads and make inter-thread RPC calls between them.)
cannam@62: 
cannam@62: [More on C++ promises.]({{ site.baseurl }}cxxrpc.html#kj_concurrency_framework)
cannam@62: 
cannam@62: ### Python too
cannam@62: 
cannam@62: [Jason](https://github.com/jparyani) has been diligently keeping his
cannam@62: [Python bindings](http://jparyani.github.io/pycapnp/) up to date, so you can already use RPC there
cannam@62: as well.  The Python interactive interpreter makes a great debugging tool for calling C++ servers.
cannam@62: 
cannam@62: ### Up Next
cannam@62: 
cannam@62: Cap'n Proto is far from done, but working on it in a bubble will not produce ideal results.
cannam@62: Starting after the holidays, I will be refocusing some of my time into an adjacent project which
cannam@62: will be a heavy user of Cap'n Proto.  I hope this experience will help me discover first hand
cannam@62: the pain points in the current interface and keep development going in the right direction.
cannam@62: 
cannam@62: This does, however, mean that core Cap'n Proto development will slow somewhat (unless contributors
cannam@62: pick up the slack! ;) ).  I am extremely excited about this next project, though, and I think you
cannam@62: will be too.  Stay tuned!