After holidays and bad colds and work trips, I'm starting to make lots of progress with WasmTime and with WASI. I've started a new emissary common class, which I am getting ready to experiment with.
I am now at the point where I have to figure out how a emissary works inside (things like how to initialize it and call it, and feed it events). So far, with WasmTime I think I have to generate a single module per webassembly file in memory (likely to change over time as wasmtime is in steady motion). This of course was far from possible with V8. I'm hoping that modules are light enough that we can have thousands, if not eventually hundreds of thousands, of these at the same time (though that might be 5 to 10 years from now -- I think computers of the future will be able to cope).
I also have kind of figured out how to handle WASI security. There are several kinds of emissaries, and they need different APIs, and the concept of the IHost at this point just lets me define one. So, I will need to put all the APIs together. I can however put a simple, "Is thing thing on?" check to disallow calls that aren't for that kind of API.
I've started a big spreadsheet to start figuring out the actual methods I need for all of the different APIs. And since I've expanded the idea of the emissary to basically encompass all most all of the VR business logic (if I can refer to it as such), with be done via an emissary.
And, since it seems like it's first the to gate, initial libraries for webassembly will be done in Rust. Though I suspect most all languages will get there eventually.
I'm also thinking of possibly using protobuf to pass the initialization and perhaps some of the more complex objects between emissary and processor rather than trying to use regular objects. I think I now need an Common Emissary Protobuf (and possibly gRPC) library, and likely a separate github repository so they can be git submodules.
I'm also starting to consider the use of rabbitMQ (AMQP) to do more event oriented work. I can even install rabbit (and erlang) onto a local windows machine. I'd have to figure out the demarcation between gRPC and AMQP. Though likely the AMQP messages will be protobuf.
I'm starting to question the windows-centric deployment of the browser -- this is likely required, though eventually I might be able to do hybrid deployment in docker on windows-10. This also might be a good solution for browser clustering. It certainly would be an easier way to deploy the messaging (amqp), and possibly the various non-ui servers (emissaries, and caches).
VR Worlds is a concept for building, essentially, an VR/AR (XR) Operating system, which allows any number of worlds to operate together and run in modern scalable containerized servers. Anyone can field their own worlds and so make their own rules rather than some giant top down architecture.
Thursday, January 23, 2020
Subscribe to:
Posts (Atom)
Random Thoughts, Some Progress
Lots of work at work, so not as much time for projects. Smattering of thoughts: Godot doesn't really seem ready for prime-time with c...
-
So, the original idea for the _payload directory in the Emissary was to allow the initial state of meshes and whatever other assets might be...
-
Interesting article on asymmetric cryptography... Don't Use RSA So, looks like I will be using Elliptic Curves with Curve 25519 . ...
-
So, I wasn't really thinking that the V8 environments in the browser would be truly compatible with node or chrome. That leads to issue...