[capnproto] Implemeting kj async(io) using webassembly?

[o***@seznam.cz]

Having the same API for both the server and the webpage would be really
helpful.

But there is more work to be done than making an implementation of
EventPort, Network and AsyncIoProvider.

For example, how to 'hold on' to JS objects?
WebAssembly can only hold/call JS functions, so store the objects in
captures? Or maintain an external map from opaque ints to objects?

Or that the way the event loop is pumped needs to be rewritten to not block
the browsers event loop. (which includes removing Promise.wait())

Also some parts would need to be removed, eg.: TLS, HTTP (unless you have
a websocket<->TCP proxy) and probably the filesystem API.
Threads could stay because they, like web workers, use streams to
communicate instead of memory.

However, my main concern is if someone else will have a use for this?
Because otherwise it's easier to just tape together some project specific
code and be done.

['Kenton Varda' via Cap'n Proto]

Hmm. If you want to make the RPC implementation work from WASM, I think the
right place to place the binding layer is in a custom implementation of
VatNetwork. At that level, you are operating on whole Cap'n Proto messages
rather than on byte streams. If you place messages into ArrayBuffers that
are shared with JavaScript, you can get the data out to JS land very
easily. I imagine you would then send the message over a WebSocket.

I *don't* think you want to try to implement AsyncIoProvider,
AsyncIoStream, Network, etc. Those are too low-level and don't map nicely
to the primitives available on the JS side. VatNetwork is a much better fit.

Now, the other question here is, is your application itself written in C++
and running in WASM, or is the application JavaScript? If it's WASM, then
we're done.

But if your application is JavaScript, then you need to decide at what
level you want to bind it to C++. I think the best choice here is *not* to
try to expose the entire serialization API to JS -- it's far too big.
Instead, what you want is to use a JavaScript implementation of
serialization (like https://github.com/jdiaz5513/capnp-ts), backed again by
ArrayBuffers shared with C++. Once the messages are constructed, you can
hand them off to the C++ RPC implementation relatively easily. Note that
the purpose of using WASM here would be solely to avoid having to rewrite
the whole RPC implementation in JavaScript. However, I'm not sure that's
the best approach -- translating the core RPC implementation may actually
be easier and more practical.

-Kenton

Post by o***@seznam.cz
Having the same API for both the server and the webpage would be really
helpful.
But there is more work to be done than making an implementation of
EventPort, Network and AsyncIoProvider.
For example, how to 'hold on' to JS objects?
WebAssembly can only hold/call JS functions, so store the objects in
captures? Or maintain an external map from opaque ints to objects?
Or that the way the event loop is pumped needs to be rewritten to not
block the browsers event loop. (which includes removing Promise.wait())
Also some parts would need to be removed, eg.: TLS, HTTP (unless you have
a websocket<->TCP proxy) and probably the filesystem API.
Threads could stay because they, like web workers, use streams to
communicate instead of memory.
However, my main concern is if someone else will have a use for this?
Because otherwise it's easier to just tape together some project specific
code and be done.
--
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
Visit this group at https://groups.google.com/group/capnproto.

[o***@seznam.cz]

Thanks for pointing out VatNetwork, that'll be much easier to implement.

My app is C++ only, but i'm unsure how to handle the browser event loop, fulfill promises on callback and then do EventLoop.run()?
And have EventPort as a no-op.

Also what do the template arguments to VatNetwork mean? VatId seems like an address, but i don't recognize any others.

['Kenton Varda' via Cap'n Proto]

Post by o***@seznam.cz
Thanks for pointing out VatNetwork, that'll be much easier to implement.
My app is C++ only, but i'm unsure how to handle the browser event loop,
fulfill promises on callback and then do EventLoop.run()?
And have EventPort as a no-op.

Yes, that sounds right.

Also what do the template arguments to VatNetwork mean? VatId seems like an

Post by o***@seznam.cz
address, but i don't recognize any others.

They relate to level 3 RPC, with three-party handoff support, which hasn't
actually been implemented yet. Details are described in rpc.capnp. You can
probably follow the example of TwoPartyVatNetwork for your use case.

-Kenton

Post by o***@seznam.cz
--
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
Visit this group at https://groups.google.com/group/capnproto.