Thanks for the feedback! > Are you set on that syntax, or would you accept patches to change it? I'm not wedded to the syntax. Maybe start a thread on the

Thanks for the feedback! > Are you set on that syntax, or would you accept patches to change it? I'm not wedded to the syntax. Maybe start a thread on the discussion group and see what people think? > Being able to set tag numbers in arbitrary order makes reading the > text format of a proto message (e.g. during debugging) much nicer, > because fields can be grouped according to their purpose rather than > whenever they happened to be added to a message. I think a text format should write fields in the order in which they appear, not the order of the numbers. These don't have to be the same order. The purpose of the numbers is to allow you to insert a new field in an arbitrary position in your struct def without breaking wire-compatibility, rather than requiring you to add all new fields at the end. Maybe the wording in the docs is confusing? > Speaking of which, I don't see any specification for a text-based > serialization format on this site. If I were you, I'd just steal > Protobuf's because it's simple and easy to read/write. I intend to support JSON transcoding. The protobuf format is kind of quirky, although it is nice that it doesn't require as much quoting. Maybe the JSON transcoder could have a "less quoted" mode that breaks standards somewhat. > For me, the reason to skip field numbers is when some older version > of the message defined some field, but new messages removed it and > clients should not know about it. In practice, you actually shouldn't do that even with protobufs, because if you accidentally reuse that field number, you might misinterpret old data. Hence the convention with protobufs is usually to rename fields to "OBSOLETE_N". Cap'n Proto can't allow you to remove fields because that would change the offsets of subsequent fields. But you can certainly rename fields. > If the C++ implementation requires advanced modern compiler features, > that will severely reduce the number of developers who are able to > use it. This is true, but C++11 features are really useful, and the implementation (and even its interface) simply would not be as good without them. If this is a big problem, perhaps someone will start maintaining a back-port to C++98, as if it were another language. > I'm fine with making assertion failures throw exceptions that "never > need to be caught", but network failures and invalid input are very > much things that should be treated as common events. I think my wording in the docs may be a little off, in that it isn't completely clear what I mean by "correct usage". Yes, clearly you should catch network errors in a distributed environment. But typically the only things you really want to know about the error are: * Should I retry? * What error message should I log / display? Cap'n Proto exceptions can be caught and will carry this information. The point is more that these are logistical issues, not correctness issues. The "correct" output of your program never depends on what exceptions were thrown -- if any exception is thrown, either you don't produce output at all, or you solve the problem and produce the same output that you would have otherwise. Exceptions are somewhat necessary in Cap'n Proto because validation happens as you walk the message tree. Having every getter possibly return an error code would be pretty painful. You can, however, configure it so that getters flip an error flag and then return a default value on error. As long as you check that error flag before outputting garbage, you should be fine. > If there's a length prefix, why bother with a terminating NUL? It's helpful if the recipient intends to use the strings in C/C++ code -- they can avoid a copy. For example, if the message contains a file name and the recipient wants to open() it, they need a NUL-terminated string, and malloc()/copying one is kind of sad. Although I want to support many languages, I expect Cap'n Proto users to be biased towards C/C++ since those are the people who care deeply about speed. > It's not obvious how such address-passing can be implemented... This is certainly a complicated problem, but solvable. I wrote some comments elsewhere: https://news.ycombinator.com/item?id=5482782 https://news.ycombinator.com/item?id=5482782 I look to things like the E programming language and Tahoe-LAFS for inspiration here. > Roughly what is the timeline for defining the RPC protocol? I'm working full-time on Cap'n Proto right now. It's always hard to predict coding timelines, but I am hoping to have something within a month or two. > it'll replace my use of D-Bus for inter-machine and low-overhead > inter-process communication Hey, that sounds like exactly the main use case I'm interested in. I want to pass messages in shared memory, so making an IPC is basically no more expensive than posting to a semaphore. This makes it more plausible to have a sandboxed process which essentially makes all its system calls via IPC to the sandbox, without as much of a speed hit. Please do join the discussion group and tell us about your work! I'd love to have your help, or at the very least exchange notes. :)