On Tue, Oct 22, 2019 at 3:01 AM 'Newbugreport' via Cap'n Proto < [email protected]> wrote:
> 1. capnproto.org has some high level documentation, but header comments > are the main documentation. Is there other documentation or samples I > should read? Perhaps a suggested reading order? > Sorry, not really at the moment. I have it on my todo list for this quarter to write real documentation for KJ... > 2. The documentation describes capnp as a capability based system. This is > a new concept to me, but Wikipedia says capabilities are object references > that can't be forged. The implementation looks more like interface > pointers. From my naive perspective this looks like a simple concept made > difficult to understand by describing it in unfamiliar terms. > 2a. I assume in capnp this reference is just the interfaceId in the rpc > protocol > <https://github.com/capnproto/capnproto/blob/master/c++/src/capnp/rpc.capnp>, > which would refer to an address or table entry on the server. Is capnp > doing anything to make the ids difficult to guess/forge/eavesdrop? > Ian did a good job answering these. Just to be extra clear: The interface ID is simply the type ID of the interface whose method is being called. This is public information derived from the schema file. An (interface id, method number) pair identifies a specific method schema. The RPC protocol does not rely on any unguessable strings; instead, each side keeps track of a table of capabilities that have been passed over the connection, much like the operating system tracks a file descriptor table for each process. > 2b. The ez-rpc header states it can only support public, singleton > capabilities without state. Yet the Calculator sample returns a Value RPC > object. This leaves me confused about what the limitations are. Am I > failing to understand something about capabilities here? > Hmm, that header comment is misleading. It's been a long time since I wrote it, but I think what I was trying to say is that it doesn't support "persistence", aka "level 2" of the RPC protocol. Experience since then has shown that it doesn't make sense to think of persistence as an RPC feature at all; instead it needs to be managed by the orchestration layer / service mesh. Cap'n Proto should be agnostic to those. In any case, ez-rpc *does* support passing capabilities. FWIW, I no longer recommend the EZ interfaces. They were probably a mistake to create and I ought to deprecate them. Instead, use TwoPartyClient and TwoPartyServer, after using kj::setupAsyncIo() to initialize the event loop. 2c. Is there a sample demonstrating capabilities, assuming the Calculator > sample doesn't? > The calculator sample does in fact demonstrate capabilities, although it's somewhat contrived. 4. The install page <https://capnproto.org/install.html> suggests linux > users download a tarball, however the tarball doesn't have samples from > git. As a user struggling to learn the system, the samples would have > helped. > Can you file an issue on GitHub suggesting they be included? 5. Could you add a capnp parameter to output .cpp files? I respect that > .c++ is a better name but there are a surprising number of places I have to > change to handle .c++ files (build scripts, editor settings). > Happy to accept a PR implementing this as an option. (You could also perhaps wrap the tool in a little script that renames the files after output.) 7. A link <https://plus.google.com/u/0/+KentonVarda/posts/D95XKtB5DhK> on > the RPC page <https://capnproto.org/cxxrpc.html> to Google Groups is not > accessible without an account. Could you move or open that document? > Oops, that link goes to a Google+ post I wrote about concurrency mechanisms. But Google+ has shut down, so the post is now gone. :( > 8. The numbers in my email didn't survive so many edits. I have the same > problem with .capnp files, and it's a surprising time sink. It occurs to me > the capnp tool could modify capnp files to fix indexes, the only piece of > missing information is which indexes already shipped and can't be changed. > This could be dangerous because renumbering a schema breaks binary compatibility (that's why the numbers exist in the first place -- to maintain compatibility across changes). I would recommend this technique: - When adding a new field, always assign it the number 1 + the previous highest number. Don't worry if the numbers end up out-of-order, that is fine. - Don't even delete fields. Rename them to add the prefix "obsolete". You can't delete a field because doing so breaks compatibility. (You can, however, reclaim the space in the message by retroactively unionizing the field with some new future field.) -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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/CAJouXQmECm8_BEbMs4dH%2BNgVcf%2BOBAP3EjxXSEhaYUtKvZe3cg%40mail.gmail.com.
