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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/47298df1-0ffc-4e6d-8cd1-cc13e4ba2e3dn%40googlegroups.com.
