David Renshaw

Hi! Looks like there a several components to what you're proposing. The first idea is to bypass the need to explicitly create a `MessageBuilder` by allowing this pattern instead: ```...

I expect that upgrading quickcheck should be straightforward. When we do that we should probably bump the version number of the capnp crates (from 0.14 to 0.15). I hesitate to...

Yeah, "work in progress" is probably no longer the best way to describe capnproto-java. I've gone ahead and removed that bit from the README. capnproto-java supports all of Cap'n Proto's...

Yes, that is accurate: the `capnp` crate still requires an allocator. I agree that it would be good to remove that requirement. To achieve that, we would need: 1. An...

We got another report of a hard fault using the alloc-cortex-m crate here: #293

@romixlab I expect there's a good chance that if you upgrade to capnp-v0.14.10 the HardFault will go away (and probably be replaced by an allocation failure).

I think that would require async trait methods, and as far as I'm aware, those are not yet available. http://smallcultfollowing.com/babysteps/blog/2019/10/26/async-fn-in-traits-are-hard/

For now my recommended workaround is to put an `async {}` block inside the trait method body.

The [calculator example](https://github.com/capnproto/capnproto-rust/blob/b89c092090fc915c410ab27c239ef10f3ea4f1ea/capnp-rpc/examples/calculator/server.rs) does some interesting things. One pitfall to watch out for is that the `&mut self` parameter of RPC methods cannot be accessed inside the async block, because...

nice!