This can be used on a method to indicate that it is used for "streaming", like:

    write @0 (bytes :Data) -> stream;

A "streaming" method is one which is expected to be called many times to transmit an ordered stream of items. For best throughput, it is often necessary to make multiple overlapping calls, so as not to wait for a round trip for every item. However, to avoid excess buffering, it may be necessary to apply backpressure by having the client limit the total number of overlapping calls. This logic is difficult to get right at the application level, so making it a language feature gives us the opportunity to implement it in the RPC layer.

We can, however, do it in a way that is backwards-compatible with implementations that don't support it. The above declaration is equivalent to:

    write @0 (bytes :Data) -> import "/capnp/stream.capnp".StreamResult;

RPC implementations that don't explicitly support streaming can thus instead leave it up to the application to handle.

An endpoint (subclass of `Capability::Server`) may override `kj::Maybe<int> getFd()` to expose an underlying file descriptor.

A remote client may use `Capability::Client::getFd()` on the endpoint's capability to get that FD.

The client and server must explicitly opt into FD passing by passing a max-FDs-per-message limit to TwoPartyVatNetwork and using Unix sockets as the transport. Nothing other than that is needed.

I was shocked to find that there was no good way to represent a multi-line literal currently. This implements C-style literals, where multiple consecutive string literals are concatenated.

I realized upon trying to use this framework in Sandstorm that proper revocation was not easy to implement as-is. It's easy enough to revoke new calls, but canceling existing calls requires implementing a custom RequestHook and such. Since revocation is arguably the most important thing one might want to do with a membrane, this should be built-in.

Fixes #336

Fixes #363.

The trick here is that you must specify the value as a separate constant with a defined type. Then, you can reference that constant where an AnyPointer is expected.

Eventually we should maybe support some sort of inline syntax that specifies a type explicitly...

Adding union into TestGenerics struct leads to compilation error
in generated header:
````cpp
In file included from external/capnproto/c++/src/capnp/test_capnp/capnp/test.capnp.c++:4:0:
external/capnproto/c++/src/capnp/test_capnp/capnp/test.capnp.h:9565:10: error: need ‘typename’ before ‘capnproto_test::capnp::test::TestGenerics<Foo, Bar>::Ug::Reader’ because ‘capnproto_test::capnp::test::TestGenerics<Foo, Bar>::Ug’ is a dependent scope
   inline Ug::Reader getUg() const;
````
Relavant parts in header file:

````cpp
template <typename Foo = ::capnp::AnyPointer, typename Bar = ::capnp::AnyPointer>
struct TestGenerics {
  ...
  struct Ug;
};

template <typename Foo, typename Bar>
class TestGenerics<Foo, Bar>::Reader {
  ...
  inline Ug::Reader getUg() const;
};
````

Compiler misses `typename` keyword before Ug::Reader.

Example:

    const data :Data = embed "some-file.dat";

Files are looked up the same way an import would be.

You can use embed when Data or Text is expected. You can also use it when a struct type is expected -- the file will be interpreted as a message using standard binary serialization.

Fix bug causing exception: "'Disembargo' of type 'senderLoopback' sent to an object that does not point back to the sender."

The problem happened when pipelined calls were made on a promised capability, but then that capability turned out to be null. The promise resolving code incorrectly interpreted this as the remote promise having resolved to a local capability (because the "null" stub capability looks local), and so it would send a Disembargo message to flush the pipeline as required. However, the remote end would receive this Disembargo message and find it is addressed to a null capability, not a capability pointing back to the sender. This was treated as a protocol error, causing the receiver to close the connection.

The solution is to explicitly identity "null" capabilities so that we can distinguish this case. This change also has the benefit that now when you copy a null capability between messages with foo.setCap(bar.getCap()), the pointer will be set null in the destination, rather than becoming a reference to a local broken capability.

Thanks to David Renshaw for narrowing this down.

Also introduce a way to copy a struct or list which applies membranes to all embedded capabilities, since this seems like it will be needed in conjuction with the above.

Unfortunately, the layout algorithm had a bug which caused incorrect layout when declaring a union whose lowest-ordinal field was of type Void and nested in an inner union. That is:

    union {
      a :union {
        b @0 :Void
        ...
      }
      ...
    }

In this case, all the fields in the struct after the Void field -- including both unions' discriminants -- would end up misplaced. Although they did not end up overlapping (and therefore the incorrect layout "worked"), the result broke schema evolution rules around "retroactive unionization".

Unfortunately, we must break compatibility with any protocol that happened to contain the above pattern. Luckily, it's a fairly obscure case. Unluckily, Cap'n Proto's own schema format contains such a pattern. Luckily, the use of this pattern was introduced in v0.6.x and therefore has not been in any release build so far.

Fix bug where capability pointers were corrupted when 'transferred', e.g. using adoptWithCaveats() or truncate().

Add ability to construct a new bootstrap capability for each connecting client based on their authenticated VatId.

Fix but where interface server's transitive superclass's methods weren't dispatched correctly -- ouch.

The 'objectId' field is now deprecated. Long-term, each vat will export no more than one "bootstrap interface" which can be obtained via 'Bootstrap'. Restoring SturdyRefs will be accomplished through higher-level interfaces specific to the VatNetwork in use.

See comments for 'Bootstrap' in rpc.capnp for more discussion.

See changes to test.capnp for example.

Currently only supported through generated code, not in the dynamic API. Not exactly sure how to expose this in the dynamic API...

Note that embedded schema structures in generated code are still incorrect.

More refactoring is needed, but this at least makes "using" aliases work correctly with generics.

Actually, let's use single digits for these otherwise they'll actually be printed in scientific notation with a '.', defeating the purpose of the test.

Appending 'f' to an integer literal doesn't make it a float. We have to add '.0' first.

Fixes #119.

Fix obscure bug where the last outgoing message (and any capabilities therein) would not get released (until a new message was sent, replacing it as the last).

This took hours to track down, because it initially looked like "Release" messages weren't being honored in some cases (when they happened to be releasing a capability from the last message, and no subsequent messages were sent). Initial attempts to capture this in a unit test failed because the test of course used a subsequent call to detect if the capability had been released, which succeeded.

For portions currently copyright by Kenton (most of it), transfer copyright to Sandstorm Development Group, Inc. (Kenton's company).

The license change is practically meaningless, as MIT and BSD 2-clause are legally equivalent. However, the BSD 2-clause license is sometimes confused for its ugly siblings, BSD 3-clause and BSD 4-clause. The MIT license is more immediately recognizeable for what it is.

Rémy Blank and Jason Choy (the two non-trivial contributors) are on record as approving this change:

https://groups.google.com/d/msg/capnproto/xXDd2HUOCcc/gbe_COIuXKYJ