Re: Cap'nProto RPC implementation questions

Hi William,

I'm the author of Cap'n Proto. I don't think I've heard about capnpy yet;
you should mention it on the Cap'n Proto dev list:

https://groups.google.com/group/capnproto

To answer your question, currently the RPC protocol supports two notions of
promises:
- A promise for the result of a method call. (Method call results are
always structs, because structs can be extended with additional fields
without breaking compatibility.)
- A promise for a capability, where a capability always points to a remote
object. From the application's perspective, a promise for a capability
actually has the same type as just a capability -- calls made to it are
pipelined.

Currently, there is no particular way to declare a promise to a
non-capability value (like a struct). The values of all of a struct's
fields, including sub-structs, are always transmitted together as a unit.
We could perhaps add value promises in the future, but for now you can fake
it using a capability to an object with a get() method. That is:

    interface RemoteValue(T) {
      get @0 () -> (value :T);
    }

    struct Foo {
      promiseForBar @0 :RemoteValue(Bar);
    }

But otherwise, all of the fields of a struct are transmitted with the
struct as one unit, including sub-structs.

-Kenton

On Wed, Nov 4, 2015 at 7:37 PM, William ML Leslie <
[email protected]> wrote:

> Hi Everyone,
>
> I'm not sure if this is quite on-topic, but I'm trying to implement
> rpc in capnpy, a pure-python Cap'nProto implementation.
>
> Cap'nProto's concept of promises is interesting:  They usually have a
> type, representing the type that the value may resolve to.  These may
> be structs in the case of an unanswered question, or they may be
> interfaces that are fields of a struct that has not returned yet.  I
> can't tell from the documentation if there's any consensus on promises
> to primitives or lists within application code, although you can't
> pass promises to either of these over the wire as far as I can tell.
> Actually, maybe you can pass promises to lists now that I think of it.
>
> From a robustness perspective, I think I want waiting on a struct to
> ensure that all of its sub-structs are resolved too; that is, that
> you're never going to index expecting to get a struct and not getting
> one.  Is that a bad idea?  Should I provide both a partial-wait and a
> full-wait?
>
> I'm really looking for any suggestions I can get on this one, or maybe
> even just some sympathy.
>
> --
> William Leslie
>
> Notice:
> Likely much of this email is, by the nature of copyright, covered
> under copyright law.  You absolutely MAY reproduce any part of it in
> accordance with the copyright law of the nation you are reading this
> in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
> prior contractual agreement.
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk