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