Did anything every come of this? On Sunday, June 16, 2019 at 6:45:40 AM UTC-7, Mark S. Miller wrote: > > (From Martin BZ and MarkM jointly) > > Hi Kenton, could you look at > > https://github.com/wanderer/WASI/tree/master/schema > > We want to suggest this to the WASI folks, to suggest that this be the way > WASI IDLs should be specified. Their current plans are to start with > WebIDL, which is rather horrible. So we'd like to send this to them as soon > as reasonable, but not sooner. So, at this stage, we're not looking for > detailed feedback on particulars, but rather, whether this is a reasonable > style for using the Cap'n Proto schema language. > > Thanks! > > > > On Sun, Jun 16, 2019 at 10:37 AM Mark S. Miller <eri...@gmail.com > <javascript:>> wrote: > >> [+Michael, +Dan] >> >> I like this direction! >> >> Where can I find a bnf for the Cap'n Proto schema/idl language? I want to >> start from there to create a concrete syntax for the Chainmail (formal >> specification language for ocap patterns) abstract syntax. I had previously >> started with a Jessie-like syntax, but I think Cap'n Proto would be a >> better place to start. As part of this, I want to write specifications for >> the ERTP and SwingSet APIs as Cap'n Proto files that I can imagine would >> grow into Chainmail specs. Together with WASM/WASI bindings for Cap'N >> Proto, this would be a start for enabling non-JS WASM instances to plug >> into our SwingSet kernel. >> >> To close this loop, we should define the subset of Cap'n Proto that we >> expect to compile to WASM/WASI bindings. SwingSet should then restrict >> itself to that subset. >> >> Is there a standard representation of the AST that a Cap'n Proto >> schema/idl file parses into? With such an AST translated to JSON, I would >> also like to explore changing our marshaling system so that it only allows >> through calls described in the IDL and made available to the comm system at >> runtime via a derived JSON representation suitable for that purpose. That >> would put us in a good position to explore eventually cerealizing to Cap'n >> Proto itself. >> >> >> >> On Sat, Jun 15, 2019 at 6:46 PM 'Kenton Varda' via Cap'n Proto < >> capn...@googlegroups.com <javascript:>> wrote: >> >>> Hi mjbecze, >>> >>> This is interesting! Is this related to: >>> >>> https://github.com/WebAssembly/design/issues/1274 >>> >>> ? >>> >>> On Sat, Jun 15, 2019 at 9:08 AM <mjb...@gmail.com <javascript:>> wrote: >>> >>>> Hello, >>>> I'm currently investigating whether capt'n proto schema would be >>>> appropriate for describing Webassebly interfaces. I'm attempting to >>>> translate this interface >>>> <https://github.com/WebAssembly/WASI/blob/master/docs/WASI-overview.md> >>>> to capn proto schema. I several questions and I'm sure I'll have more as >>>> the work progresses. >>>> >>>> 1. Webassebly will soon have opaque references >>>> <https://github.com/WebAssembly/reference-types>. How would you >>>> represent reference types in capt'n proto? >>>> >>> >>> Cap'n Proto's "Capability" type is exactly what you want here: it >>> represents an external reference to "something". Note that interface types >>> in Cap'n Proto are all subclasses of "Capability" -- i.e. "Capability" is >>> kind of like Java's "Object". But it's totally valid to use just the type >>> "Capability" to represent a handle to some opaque thing that has no >>> particular methods you can call. >>> >>> Also worth noting that in Cap'n Proto's real RPC system, capabilities >>> are referenced through table indices, just like Wasm opaque references >>> apparently will be. Check out: >>> >>> >>> https://github.com/capnproto/capnproto/blob/77f20b4652e51b5a7ebda414e979e059a6c7c27c/c++/src/capnp/rpc.capnp#L116 >>> >>> Also, Cap'n Proto's C++ implementation has the ability to attach file >>> descriptors to capabilities and pass them between processes (via SCM_RIGHTS >>> on unix sockets): >>> >>> https://github.com/capnproto/capnproto/pull/821 >>> >>> So there's lots of precedent here. >>> >>> 2. Is annotation the correct way to represent pointers? for example >>>> >>> >>> Oof, this is pretty awkward, especially in that it presumes the callee >>> has the ability to reach into the caller's address space. Obviously, Cap'n >>> Proto hasn't been designed with that sort of thing in mind. >>> >>> With that said, I like your second solution, transforming return values >>> into things that are stored to the pointer. This allows the schema to >>> express the semantics in a way that makes sense for classic RPC, and then >>> return-by-write-to-pointer becomes part of the "calling convention" that >>> maps Cap'n Proto to Wasm. >>> >>> -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 capn...@googlegroups.com <javascript:>. >>> Visit this group at https://groups.google.com/group/capnproto. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/capnproto/CAJouXQ%3DYWW-L4Rp5JZHD5CGTbhiKypWuoP5HJ10CxKqL8A6Z%3Dg%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/capnproto/CAJouXQ%3DYWW-L4Rp5JZHD5CGTbhiKypWuoP5HJ10CxKqL8A6Z%3Dg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> Cheers, >> --MarkM >> > > > -- > Cheers, > --MarkM >
-- 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/e9ee73e2-9950-45f6-ba83-c8864f217a32%40googlegroups.com.
