[kentonv]

I look forward to hearing from you, should you decide to contribute. :) A web socket transport for Cap'n Proto would make a lot of sense, particularly if paired with a Javascript implementation, which one or two people have claimed they might create. I expect it will be easy to hook this in as a transport without disturbing much of the RPC implementation.

[btilly]

One random idea that just hit me if you're thinking about RPC layers anyways. Make sure that Cap'n Proto plays well with 0MQ. They probably do already, but a published example or two demonstrating it would not be a bad thing.

[kentonv]

You can certainly send Cap'n Proto messages over 0MQ (or nanomsg) pretty easily -- Cap'n Proto gives you bytes, 0MQ takes bytes. Done deal.

However, supporting Cap'n Proto's planned RPC system on top of 0MQ may not work so well. The thing is, 0MQ implements specific interaction patterns, such as request/response, publish/subscribe, etc. Meanwhile, Cap'n Proto RPC is based on a different, more fundamental object-oriented model that doesn't fit into any of these patterns. A Cap'n Proto connection does not have a defined requester or responder -- both sides may hold any number of references to objects living on the other side, to which they can make requests at any time. So it fundamentally doesn't fit into the req/rep model, much less things like pub/sub. On the other hand, you can potentially build a pub/sub system on top of Cap'n Proto's model (as well as, trivially, a req/rep system).

I discussed this a bit on the mailing list:

https://groups.google.com/d/msg/capnproto/JYwBWX9eNqw/im5r_E...

At least, this is my understanding based on what I've managed to read so far of 0MQ's docs. I intend to investigate further, because it would be great to reuse existing work where it makes sense, but at the moment it isn't looking like a good fit. If I've missed something, definitely do let me know.

[btilly]

The killer feature that I like for 0MQ is that you can support message passing asynchronously, even when the other side is not currently up. For instance in a request/response pattern, one side might go away, get restarted, reinitialize, and then they carry on as if there wasn't a period in the middle where there was no connection. This kind of robust handling of network interruptions is very convenient for many use cases.

However what you describe isn't necessarily going to fit into that. The #1 thing that your description makes me wonder about is whether RPCs are going to be synchronous or asynchronous. So, for instance, if you hand me a data structure with a list objects that are references to data that I want to have, and I decide that I need 10 of them, do I have to pay for the overhead of 10 round trips, or can I say, "I need these 10" and get them all at once?

[kentonv]

> support message passing asynchronously, even when the other side is not currently up.

That's probably something that could be implemented in Cap'n Proto as some sort of a persistent transport layer. But since the connections are stateful, it does require that when one end goes down, it comes back up with its state still intact. I have a lot of ideas for how to make this possible it big systems but it's a long way off.

Of course, in the simple case where you do have a defined client and server and the server is only exporting one stateless global service object that the client is using -- which is roughly what 0mq req/rep sockets are for -- then it should be no problem to support this.

> whether RPCs are going to be synchronous or asynchronous

The interface will be asynchronous based on E-style promises (similar to futures). In fact, say you call an RPC which returns a remote object reference, and you immediately want to call another method on that reference. With Cap'n Proto's approach, you will be able to do this whole interaction in one round trip instead of two. This is called "Promise Pipelining". There's a bit (just a bit) more detail here:

http://kentonv.github.io/capnproto/rpc.html

[srollyson]

Looks like I might end up working Cap'n Proto after all. I've no experience with 0MQ, but it seems if Cap'n Proto's RPC is designed flexibly enough it would at least be able to support exclusive pairs as described on 0MQ's Wikipedia page [1]. I'll try to keep it in mind in whatever proposals I have w.r.t. the RPC design. Thanks for the suggestion, Ben!

[1]: https://en.wikipedia.org/wiki/%C3%98MQ#Technology