Ian Denhardt

Pushed a tweak; this now also protects some process-specific state, which transfers ownership during shutdown. I think this will be really nice to work with.

...I wonder if we shouldn't be agressively pulling stuff out of the rpc package and into small, self contained packages under `internal/`; sender.go is pretty self contained, and it would...

I should probably test it still, at least.

I still think it's a good idea, it just hasn't made it to the top of my priorities list. Are you blocked on this for something you have in mind,...

Ok. No promises on timeline, but it's not actually api visible anyway (as of this patch, it's actually just dead code).

Hope it's cool if I think out loud on this thread. One obvious strategy: we need an injective function from legal capnproto idenfiers to legal go identifiers that don't collide...

For characters in filenames that don't constitute legal go package names, we can replace them with strings that start with a double underscore, e.g. `c++.capnp` generates a package named `c__plus__plus`....

Obviously, a lot of these techniques are going to cause source-level breakage, don't know how you want to handle that.

We could also just make go-capnpc use names with a trailing underscore, that don't otherwise conflict with go keywords. This would let us introduce new ones without worrying about disturbing...

One other thing that needs thinking about; what do we do about importing different schema with the same filename, and therefore package name? e.g. "/foo/mypackage.capnp" and "/foo/mypackage.capnp". I there's a...