Hi Jonathan, On Fri, Mar 17, 2023 at 2:10 PM Jonathan Shapiro <s...@buttonsmith.com> wrote:
> I missed one under semantics: > > - capn-proto structs are defined as reference (pointer) types, while > protobuf message types appear to be value types. > > Does capn-proto support the case where a single struct is referenced from > multiple places? That is: does it support graphs as messages? > I think you might be confusing semantics vs. encoding details here. Structs are *encoded* using a pointer that points to the content located elsewhere in the message buffer. However, they nevertheless behave like value types. The semantics are just about exactly the same as in Protobuf. Cap'n Proto does not support graphs. Given the use of pointers, it may be obvious how graphs would be encoded, if we supported them. The problem with graphs is that they make so much else in the implementation vastly more complicated. For example, say I do `message1.setFoo(message2.getFoo())`, where `foo` has a struct type. We have to copy `foo` from one message buffer into another. With trees, this is a trivial recursive operation. But if graphs are allowed, now we must maintain a lookup table to remember which pointers we've already followed. Moreover, if on the next line I do `message1.setBar(message2.getBar())`, and it turns out `foo` and `bar` both pointed to a common third object, how do we make sure we don't make a redundant copy of that? It seems we now have to maintain a mapping table long-term for any pair of messages for which copies have occurred. On the use case front, it seems to me that the two are optimized for >> different situations: >> >> - The gRPC+protobuf encoding scheme is optimized for use over lower >> bandwidth links, but embeds the assumption that decoding upon receipt will >> proceed linearly and to completion (because random access isn't >> straightforward). >> - The capn-proto encoding scheme is optimized for local area RPC >> and/or out-of-process plugins, where communication bandwidth isn't much of >> a limiting factor but efficient transmission (perhaps even by mmap) >> matters. >> >> Note that Cap'n Proto's serialization is not primarily designed for RPC at all, and indeed most users use the serialization but not the RPC. The serialization's biggest wins come when used as a format for large files that are read using mmap(). When it comes to RPC, the serialization might lend itself nicely to communications via shared memory, but I'm not sure if anyone has actually tried that (yet). I would not necessarily say that protoobuf is "optimized" for low bandwidth. When using a low-bandwidth link, I would highly recommend applying compression to either format, which will have greater impact than Protobuf's encoding techniques (and will narrow the gap created by those techniques). -Kenton -- 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 capnproto+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/CAJouXQkWkAEZLVH2zOvywB0pf1-56WMfviQf47E1xBa4Thi%3DmA%40mail.gmail.com.
