Hmm. Arguably the bug is that the v8 capnp bindings don't accept an arbitrary stream here.
I hesitate to make TLS something that is "built in" to the library, since we'd then be stuck with it even after we have a better transport -- and we'd be bloating all the people who don't actually want it. I think we need to keep it as a separable dependency. -Kenton On Thu, Mar 9, 2017 at 1:12 PM, Tony Arcieri <[email protected]> wrote: > On Thu, Mar 9, 2017 at 1:08 PM, Kenton Varda <[email protected]> wrote: > >> As Ian says, it's straightforward to layer Cap'n Proto's "two-party" RPC >> (which is the only thing that anyone uses currently) on top of TLS, since >> it accepts an arbitrary abstract I/O stream. This should only take a few >> lines of code. So I, too, wonder what "first-class" support would mean. >> > > As an example of where things aren't straightforward: the Node.js RPC > client: > > https://github.com/kentonv/node-capnp > > // connect() accepts the same address string format as kj::Network. > var conn = capnp.connect("localhost:1234"); > > How do I use TLS here? It's abstracting over the socket. Is there a > separate API I can use to pass in a TLS socket? > > To me first class support would entail at least the following: > > - Ensuring there is a strategy for using TLS with all of the extant capnp > RPC implementations in every language > - Documenting how to use TLS for each implementation > > -- > Tony Arcieri > > -- > You received this message because you are subscribed to the Google Groups > "Cap'n Proto" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > Visit this group at https://groups.google.com/group/capnproto. > -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/capnproto.
