cannam@48: --- cannam@48: layout: post cannam@48: title: "Cap'n Proto 0.5: Generics, Visual C++, Java, C#, Sandstorm.io" cannam@48: author: kentonv cannam@48: --- cannam@48: cannam@48: Today we're releasing Cap'n Proto 0.5. We've added lots of goodies! cannam@48: cannam@48: ### Finally: Visual Studio cannam@48: cannam@48: Microsoft Visual Studio 2015 (currently in "preview") finally supports enough C++11 to get Cap'n cannam@48: Proto working, and we've duly added official support for it! cannam@48: cannam@48: Not all features are supported yet. The core serialization functionality sufficient for 90% of users cannam@48: is available, but reflection and RPC APIs are not. We will turn on these APIs as soon as Visual C++ cannam@48: is ready (the main blocker is incomplete `constexpr` support). cannam@48: cannam@48: As part of this, we now support CMake as a build system, and it can be used on Unix as well. cannam@48: cannam@48: In related news, for Windows users not interested in C++ but who need the Cap'n Proto tools for cannam@48: other languages, we now provide precompiled Windows binaries. See cannam@48: [the installation page]({{site.baseurl}}install.html). cannam@48: cannam@48: I'd like to thank [Bryan Boreham](https://github.com/bboreham), cannam@48: [Joshua Warner](https://github.com/joshuawarner32), and [Phillip Quinn](https://github.com/pqu) for cannam@48: their help in getting this working. cannam@48: cannam@48: ### C#, Java cannam@48: cannam@48: While not strictly part of this release, our two biggest missing languages recently gained support cannam@48: for Cap'n Proto: cannam@48: cannam@48: * [Marc Gravell](https://github.com/mgravell) -- the man responsible for the most popular C# cannam@48: implementation of Protobufs -- has now implemented cannam@48: [Cap'n Proto in C#](https://github.com/mgravell/capnproto-net). cannam@48: * [David Renshaw](https://github.com/dwrensha), author of our existing Rust implementation and cannam@48: [Sandstorm.io](https://sandstorm.io) core developer, has implemented cannam@48: [Cap'n Proto in Java](https://github.com/dwrensha/capnproto-java). cannam@48: cannam@48: ### Generics cannam@48: cannam@48: Cap'n Proto now supports [generics]({{site.baseurl}}language.html#generic-types), cannam@48: in the sense of Java generics or C++ templates. While working on cannam@48: [Sandstorm.io](https://sandstorm.io) we frequently found that we wanted this, and it turned out cannam@48: to be easy to support. cannam@48: cannam@48: This is a feature which Protocol Buffers does not support and likely never will. Cap'n Proto has a cannam@48: much easier time supporting exotic language features because the generated code is so simple. In cannam@48: C++, nearly all Cap'n Proto generated code is inline accessor methods, which can easily become cannam@48: templates. Protocol Buffers, in contrast, has generated parse and serialize functions and a host cannam@48: of other auxiliary stuff, which is too complex to inline and thus would need to be adapted to cannam@48: generics without using C++ templates. This would get ugly fast. cannam@48: cannam@48: Generics are not yet supported by all Cap'n Proto language implementations, but where they are not cannam@48: supported, things degrade gracefully: all type parameters simply become `AnyPointer`. You can still cannam@48: use generics in your schemas as documentation. Meanwhile, at least our C++, Java, and Python cannam@48: implementations have already been updated to support generics, and other implementations that cannam@48: wrap the C++ reflection API are likely to work too. cannam@48: cannam@48: ### Canonicalization cannam@48: cannam@48: 0.5 introduces a (backwards-compatible) change in cannam@48: [the way struct lists should be encoded]({{site.baseurl}}encoding.html#lists), in cannam@48: order to support [canonicalization]({{site.baseurl}}encoding.html#canonicalization). cannam@48: We believe this will make Cap'n Proto more appropriate for use in cryptographic protocols. If cannam@48: you've implemented Cap'n Proto in another language, please update your code! cannam@48: cannam@48: ### Sandstorm and Capability Systems cannam@48: cannam@48: [Sandstorm.io](https://sandstorm.io) is Cap'n Proto's parent project: a platform for personal cannam@48: servers that is radically easier and more secure. cannam@48: cannam@48: Cap'n Proto RPC is the underlying communications layer powering Sandstorm. Sandstorm is a cannam@48: [capability system](http://www.erights.org/elib/capability/overview.html): applications can send cannam@48: each other object references and address messages to those objects. Messages can themselves contain cannam@48: new object references, and the recipient implicitly gains permission to use any object reference cannam@48: they receive. Essentially, Sandstorm allows the interfaces between two apps, or between and app cannam@48: and the platform, to be designed using the same vocabulary as interfaces between objects or cannam@48: libraries in an object-oriented programming language (but cannam@48: [without the mistakes of CORBA or DCOM]({{site.baseurl}}rpc.html#distributed-objects)). cannam@48: Cap'n Proto RPC is at the core of this. cannam@48: cannam@48: This has powerful implications: Consider the case of service discovery. On Sandstorm, all cannam@48: applications start out isolated from each other in secure containers. However, applications can cannam@48: (or, will be able to) publish Cap'n Proto object references to the system representing APIs they cannam@48: support. Then, another app can make a request to the system, saying "I need an object that cannam@48: implements interface Foo". At this point, the system can display a picker UI to the user, cannam@48: presenting all objects the user owns that satisfy the requirement. However, the requesting app only cannam@48: ever receives a reference to the object the user chooses; all others remain hidden. Thus, security cannam@48: becomes "automatic". The user does not have to edit an ACL on the providing app, nor copy around cannam@48: credentials, nor even answer any security question at all; it all derives automatically and cannam@48: naturally from the user's choices. We call this interface "The Powerbox". cannam@48: cannam@48: Moreover, because Sandstorm is fully aware of the object references held by every app, it will cannam@48: be able to display a visualization of these connections, allowing a user to quickly see which of cannam@48: their apps have access to each other and even revoke connections that are no longer desired with cannam@48: a mouse click. cannam@48: cannam@48: Cap'n Proto 0.5 introduces primitives to support "persistent" capabilities -- that is, the ability cannam@48: to "save" an object reference to disk and then restore it later, on a different connection. cannam@48: Obviously, the features described above totally depend on this feature. cannam@48: cannam@48: The next release of Cap'n Proto is likely to include another feature essential for Sandstorm: the cannam@48: ability to pass capabilities from machine to machine and have Cap'n Proto automatically form direct cannam@48: connections when you do. This allows servers running on different machines to interact with each cannam@48: other in a completely object-oriented way. Instead of passing around URLs (which necessitate a cannam@48: global namespace, lifetime management, firewall traversal, and all sorts of other obstacles), you cannam@48: can pass around capabilities and not worry about it. This will be central to Sandstorm's strategies cannam@48: for federation and cluster management. cannam@48: cannam@48: ### Other notes cannam@48: cannam@48: * The C++ RPC code now uses `epoll` on Linux. cannam@48: * We now test Cap'n Proto on Android and MinGW, in addition to Linux, Mac OSX, Cygwin, and Visual cannam@48: Studio. (iOS and FreeBSD are also reported to work, though are not yet part of our testing cannam@48: process.)