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? Thanks! On Friday, March 17, 2023 at 11:43:49 AM UTC-7 Jonathan Shapiro wrote: > So I've been much-belatedly looking at capn-proto lately, and I'd like to > see if I understand the key differences between CapnProto and gRPC. > > I'm not interested so much in the surface syntax differences. Right now > I'm not paying attention to Level 3 either - I'm already familiar with > MarkM's work on CapTP and E. > > The essential *semantic *differences seem to be: > > - Interface definitions define a type, and interface *references* can > be carried in messages. > - More specifically, interfaces define an *object* type - there's an > implicit object identity embedded in each interface instance, which is > passed with each method invocation. > - Method arguments are first class. The gRPC approach on this always > seemed like a really bad decision. > - There's a very reasonable take on a module system. Having fought > with this on the GraphQL front for a while, it's really nice to see. > - Method results are returned as promises. Creatively used, these > subsume any need for streams. > - capn-proto is less obsessively wire-centric; the impedance matching > between what the consuming client or server wants to see and the protocol > layer wants to see seems *much* better handled. > > 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. > > > > What have I missed here that is fundamental? Having worked a fair bit > with both gRPC and GraphQL, I have one or two *really* minor thoughts for > enhancement; mainly things that already seem to be implicitly present > should be made explicit. > > Aside from some of the individual language mappings, capn-proto looks > *really* good. And all of the language mapping complaints reflect > constraints of the target language rather than capn-proto. Which, given the > real care that Kenton put in to this, doesn't suggest favorable things > about one or two of those languages. :-) > > > Jonathan Shapiro > -- 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/47298df1-0ffc-4e6d-8cd1-cc13e4ba2e3dn%40googlegroups.com.
