The first release of Cap'n Proto came three months after the project was announced. The second release came six weeks after that. And the third release is three weeks later. If the pattern holds, there will be an infinite number of releases before the end of this month.
Version 0.3 is not a paradigm-shifting release, but rather a slew of new features largely made possible by building on the rewritten compiler from the last release. Let's go through the list...
Thanks to the tireless efforts of contributor Jason Paryani, I can now comfortably claim that Cap'n Proto supports multiple languages. His Python implementation wraps the C++ library and exposes most of its features in a nice, easy-to-use way.
And I have to say, it‘s way better than the old Python Protobuf implementation that I helped put together at Google. Here’s why:
.capnp
schema file as if it were a .py
module. It’s even convenient to load schema files and play with Cap'n Proto messages from the interactive interpreter prompt.Go check it out!
By the way, there is also a budding Erlang implementation (by Andreas Stenius), and work continues on Rust (David Renshaw) and Ruby (Charles Strahan) implementations.
The capnp
command-line tool previously served mostly to generate code, via the capnp compile
command. It now additionally supports converting encoded Cap'n Proto messages to a human-readable text format via capnp decode
, and converting that format back to binary with capnp encode
. These tools are, of course, critical for debugging.
You can also use the new capnp eval
command to do something interesting: given a schema file and the name of a constant defined therein, it will print out the value of that constant, or optionally encode it to binary. This is more interesting than it sounds because the schema language supports variable substitution in the definitions of these constants. This means you can build a large structure by importing smaller bits from many different files. This may make it convenient to use Cap‘n Proto schemas as a config format: define your service configuration as a constant in a schema file, importing bits specific to each client from other files that those clients submit to you. Use capnp eval
to “compile” the whole thing to binary for deployment. (This has always been a common use case for Protobuf text format, which doesn’t even support variable substitution or imports.)
Anyway, check out the [full documentation]({{ site.baseurl }}capnp-tool.html) for more.
The core product has been updated as well:
schema.capnp
have been radically refactored, in particular to take advantage of the new union and group features, making the code more readable.Some news originating outside of the project itself: