If you're interested I have added explanatory comments to the socket-level
protocol definition for Captain Proto (formerly pbcap):
http://code.google.com/p/capnproto/source/browse/proto/capnproto.proto
I still have no conventions for HTTP transport.
On Thu, Dec 10, 2009 at 3:33 PM, Kenton Varda
Disclaimer: I'd be happy if once one of raw async RPC would be
'standart' but now maybe HTTP one will be. They just suppliment each other.
On Thu, Dec 10, 2009 at 09:41:15AM -0800, Mikhail Opletayev wrote:
Re the sockets point also raised; there's a lot of difference between raw
sockets and
On Thu, Dec 10, 2009 at 8:13 AM, Mikhail Opletayev opleta...@gmail.comwrote:
It's great news that you working on a standard way to communicate
between Protocol Buffers implementations!
You don't need to send the service name at all. The server should
already
know what kind of service it
BTW, I haven't defined how pbcap/Captain Proto will work over HTTP yet. So,
I'm only talking about the raw-socket protocol.
On Thu, Dec 10, 2009 at 2:42 PM, Kenton Varda ken...@google.com wrote:
On Thu, Dec 10, 2009 at 2:37 PM, Mikhail Opletayev opleta...@gmail.comwrote:
Interesting.
On Dec 10, 2009, at 18:33 , Kenton Varda wrote:
client: Open service Foo.
client: When request 1 is complete, call method Bar() on the
result.
I'm curious: Why have the Open request at all? Why not just cal
method Foo.Bar()? Are you planning on supporting some concept of
sessions?
On Thu, Dec 10, 2009 at 4:07 PM, Evan Jones ev...@mit.edu wrote:
On Dec 10, 2009, at 18:33 , Kenton Varda wrote:
client: Open service Foo.
client: When request 1 is complete, call method Bar() on the result.
I'm curious: Why have the Open request at all? Why not just cal method
