Ian Denhardt

Maybe add this to the v3 milestone? Allowing it to be a breaking change opens up a lot of options.

I'm *tempted* to take a whack at this (I futzed around with the low-level serialization the other night). Based on the doc @256dpi linked, the wire protocol does look pretty...

Hm, I'm not sure I fully understand your suggested workaround. Suppose I have a schema: ```capnp struct Foo { someField @0 :Data; } ``` ...and I want to allocate `someField`...

Related, we've talked in the past about having the code generator try to infer package names & import paths, see e.g: https://github.com/capnproto/go-capnproto2/issues/47

As you suspected, (I think) this is causing problems trying to do stuff with WebSession. I'm getting these errors on the console for [irc-idler](https://github.com/zenhack/irc-idler): ``` 2016/05/23 17:44:18 rpc: unknown capability...

My guess is that's not going to cut it, but I should do some more digging before I let you quote me on that. It's not what I'm hitting right...

Looks like the v3 branch has regressed on this; recvCap doesn't have a case for senderPromise. Any reason not to implement the same workaround there as we did for the...

I think this probably doesn't need to be on the v3 milestone; it's all internals, so shouldn't require breaking compatibility to address. Any objections to removing it?

Thanks for getting the ball rolling on this. Some low hanging fruit: Message should implement io.WriterTo and io.ReaderFrom. This avoids needing to create an encoder/decoder for one message. A lot...

Some thoughts: - I'm not religiously opposed to functional options, but I agree it's a bit of complexity that would be better avoided unless it buys us something really nontrivial....