add support for RPC

[couchand]

I haven't seen anything about the state of work on RPC support (other than a few cryptic comments around the repo). It's something I'm interested in, and I am aware it's a pretty sizeable project, so I figured a good concrete step is to try to identify what needs to be done to get there.

Perhaps consider this a tracking issue for the general goal of RPC support.

So, here is my attempt at documenting the steps needed to get there. There is probably a lot of detail that I'm missing, but hopefully we can flesh it out here.

• generate code for interfaces
  • interface generation (non-generics) (implemented in [WIP] feature(rpc): generate classes for interfaces (non-generics) #91)
    • root interface
    • method params & results
    • client basics
      • forwarding methods
    • server basics
      • implementation stubs
      • dispatch methods
  • generate interfaces for generic methods
  • interface type references
    • name resolution
    • has, adopt, and disown methods for interface references
    • lists of interfaces
  • ??
• runtime support
  • stub types to support generation
  • complete support type definitions
  • ezrpc runtime
  • general purpose configurable rpc runtime
  • ??

[jdiaz5513]

I have yet to take the time to fully grok the reference RPC implementation; hence the cryptic comments. This is basically first thing in my personal TODO. I'll help fill this out afterward.

Also, glad to have the help! I have time right now for code review, but not a whole lot else.

[zenhack]

The current state of this as I understand it:

• @fasterthanlime did most of the implementation work here, with an implementation on the rpc branch of his fork.
  • IIUC it uses node finalizers, so would have to switch to FinalizationRegistry for that to work in the browser.
    • We should probably also provide an explicit .close() method, since many capnp APIs expect you to be able to promptly drop referneces in order to trigger side effects.
  • It appears the code generation is not entirely complete; in particular some of the generics related code in the compiler
    plugin emits typescript errors re: missing variables.
• @CGamesPlay has a fork where he's updated the dependencies of @fasterthanlime's work. He says he's gotten a simple client-server demo going with it somewhere.
• I have my own fork, where I've built on @CGamesPlay's work and replace Bluebird promises with standard ES promises (which I assume post-date @fasterthanlime's work).
• @jdiaz5513 has been dormant due to a job that wouldn't let him work on FOSS stuff, but that has recently changed.

Relevant mailing list thread: https://groups.google.com/g/capnproto/c/oMQEuOI0xW8

@jdiaz5513, any updates on your end?

[CGamesPlay]

The "somewhere" is presently only on my local machine--I didn't built a self-standing POC for it, but rather directly starting integrating it into my application. I have a capnp-go peer which hosts a web socket server which is connected to by capnp-ts. The relevant glue code on the TypeScript side is in this gist, which I believe should actually be part of any capnp-ts library which provides RPC support. The go side of it is really straightforward, but in the interests of completeness here is a sample implementation. Using these two things, and my fork of the repo, I'm able to pass capabilities between the two peers and everything appears to work correctly.