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