Doing some Rethinking

So, I've been progressing somewhat with Emissaries...   

But, I have been doing a little rethinking.   First, if I go with Unity as the browser platform (as I have), it might make sense to look harder at Wasmer (github), rather than WasmTime (github).   Wasmer is available in .net standard 2.0, which will permit it to run directly in Unity, rather than requiring me to build out the multi-process architecture initially to make it so that I can call WasmTime WebAssembly via a separate Emissary process.   This would be much easier as an initial effort, and would make is possible to have Entities that can directly interact with the browser engine.   I'm also very interested in the WAPM effort, which is the WebAssembly -Package Manager--inspired by NPM.   I think this is basically a linker, possibly even a dynamic-linker.  It's something I thought we'd need sooner rather than later...  Ultimately we want WebAssembly modules to act like shared libraries, so that only one instance of a given module need to be in memory on a given emissary server.

However, an even bigger and more momentous change, I'm starting to look at Godot games engine.   It's not nearly as sophisticated as Unity (Unreal doesn't seem like it's any kind of fit for what I need).   Also, I'm essentially building what Unity calls a "platform".   This isn't something you're really supposed to do in Unity, though since it would be open source and would probably not really be charging money for it (at least directly, I would like to be able to monetize it somewhat---consulting, hosting, or something Patreon-like), I may or may not get into issues.   It also might be something Unity would be interested in sponsoring if this became popular.  You never know.

But, Godot is MIT license and includes all the sources.   It seems like it's got a good following, and a small but very talented core team.    Exposing the Godot API into wasm might even be something the Godot group would be enthusiastic about--it would be the holy-grail of scripting, not being tied to any particular language--though VRWorlds requires more sandboxing than that.  Perhaps the compromise there is to permit the sandbox to be created, and what APIs are exposed to it are done at creation (some level of WASI and Godot API or VRWorlds APIs can be specified).   As WASI embeddable WebAssembly capable languages start to become more plentiful (again, that's pretty much just Rust, C, C++, and maybe Javascript for now), this might become very attractive.

Godot does support procedural geometry, which we need since we don't really use the games engine to directly manage our content--it gets loaded with the emissaries.

GD script seems appealing.  I really enjoy python (though I  despise JavaScript).    It might even be worthwhile to dispense with c# and just do the interface code in GD and embed wasmer or wasmtime in c++ (theoretically it can also be done dynamically in GD script)--c# is apparently a brand new feature.   I can also put it into the engine myself, since all of the code is on GitHub.   So, I will be soul-searching and learning Godot a bit more.   It's possible that they might grow up together.  Obviously a smaller open-source project is riskier than a big commercial effort like Unity, but perhaps it will turn out somewhat like Blender did.

I can write modules directly in C and C++.   This might permit a lot of the frame-buffer operations I want to do to be very fast as opposed to having to write lots of unsafe pointer code in C#, though it's possible to call C/C++ from C# with interop.

Emissary Architecture Starting to Take Shape

So, I've been pretty deep in WASM architecture, and the WASI APIs.   I've pretty much gotten to the point where we can launch an emissary and interact with it.    So, now, it's time to actually build out the 3DOM APIs for interacting with the emissary and the message passing loops.   Initially I'm going to start building a Rust Module for this.  I do want to do this with other languages as it becomes practical.   I'd love to be able to do C# and Python, but I don't think they're quite there yet.   I've used mono-wasm to generate c# wasm, and pyodide for Python, but so far they're not particularly oriented to WASI yet and are more intended to run on a website (and interact with a DOM).

I think it will mostly go like this: one exposed setup method from the API layer, which will receive a protobuf buffer.   This will be using 'proto 3' and will be decoded and processed.  This gives us a backward and forward compatible startup.    The startup will register callbacks on the rust side for the message pump to process.   Then the emissary's 'main' basically returns.    A channel is created via grpc to the browser and eventually to the entity/avatar server.  Protobuf packets are passed in via these callback mechanisms.   The emissary runs and then returns and possibly returns one or more protobuf packets.   For now, I don't intend the emissary to have a thread to run when it is not processing a callback.   Initially I'd rather an emissary not be able to do things like mining bitcoin or other such undesirable activity.   The service managing the emissary will probably have a call timeout and will disable it if it doesn't respond in a timely fashion.

This facility kind of makes it hard to directly do gRPC, but at least we can do gRPC-like behavior passing protobufs around.   I can cheat and have a grpc wrapper call which contains a command type and the protobuf  as a raw vector.   The server calls are tricker, as the interior emissary-to-server gRPC calls are theoretically private (and ad-hoc)--so their formats can't be known by this middleware layer which is operating the emissary for the browser.    There are some up-and-coming grpc proxies out there.   Or I will have to do my own, which is just calling methods on the emissary and returning an answer (no actual network involved).   With my WASI layer, I could actually permit the emissary to open a socket, but I don't trust this yet. 

So, now I actually have to work out exactly what the browser-emissary interaction (which I've been calling the 3DOM api) actually is and how it works.   I've got some prototypes of this that I worked out last summer, but now I have to start building my .proto files to implement it.

Initially there will be no world, and no entity server to work this out.  I'll have the concept of a "system entity", which can simply run inside the loading area (which will eventually will become a mini-world which is served from inside the browser).   Also, eventually we'll have an avatar server, but initially the avatar is mostly just a vr camera FPS rig, with no smarts.    I'll be doing some checkins soon of some of this structure. 

The emissary will have an initial built-in parasitic overhead to have to have a copy of the loading module and the protobuf module.  Eventually I'm sure I'll be able to dynamically link such things so they can be shared between emissaries.   There's an effort for a package manager for webassembly (like npm) called wapm.  Perhaps there can be a package manifest and emissaries can be dynamically loaded.   I am ultimately intending for there to be hundreds, if not tens of thousands of emissaries to exist (in the distant future).   So optimization, sharing, hot-deploy, and versioning will have to be seamless.

Webassembly Madness

Spent a lot of time over the weekend getting webassembly jammed into my brain and tooling up.

I looked hard at mono-wasm (now built into the mainline distribution).   It was generating huge wasm files, so putting lots of code I wasn't explicitly adding into it.  I have to look much harder at this.   It seems like they're making an attempt to get the .net foundation classes implemented (though a lot of the code basically throws a "Not Implemented" error).   Still looks promising.  I'd rather the first gen emissaries be c#.   It's not really focused at WASI and embedding yet.  I think the emphasis is mostly for browser use and the DOM.

Discovered that there's a PyPi module with wasmtime in it, so I can embed that and make a test framework.  Trying to get my hello-world modules working in Rust and establishing the tool-chain for all of that.

They split out the wasmtime .net framework into a new package.  I think perhaps that they utterly redid the API, though it seems much easier to use.   It doesn't have to discover the host-wasi modules via reflection, so I can have a call which sets up which api's are available to each class of emissary (a method call can define each method).

I need to learn webassembly assembler.   It's been a good 40+ years since I did assembler regularly, but this one might end up being the ultimate superset assembler.   It would be interesting to build a real assembler for it (rather than the lisp-like fully regularized syntax it has now).