How the Servers Work

So, I've been thinking somewhat on how the servers actually are going to work.  I had though to them initializing and handling their security and bringing up the web services that happen at the top level (the fixed gRPC channels).  Though, except for the example content, I had always thought that implementors will simply add code to the system. 

I'm not thinking now that that's going to be best way to do this.   I've started thinking of the Emissary idea that I had for the client, and am thinking of possibly extending that to the server side.  I was never thinking that the server needed to be sandboxed like the client would, but maybe it would make sense to have a similar technology on the server (which as a starting name, I'm calling the Coordinator).   Basically the Coordinator would handle the server logic for one or more client side Emissary.   The servers would handle a lot of types of infrastructure natively that the Coordinator could take advantage of and make calls to though the APIs.

This all depends on the V8 engines and the Microsoft ClearScript engine working in .net Core (though this is where everything is going, it's likely to work).  The server would be a lot more capable of handling multiple servers and V8 threads to handle some scale-out on the server.

Even with an engine like this, other parts of the server should be written in a plugin-friendly way.  Where a set of C# assemblies that conform to the proper interfaces can be consumed by the server and loaded up at runtime.  The thought runs, that, for example, the world-persistence layer might be written to use Mongo, but a different persistence layer might be added which persists in, say, MSSQL.  So, have to think ahead about what things might need overloaded functionality which could be pluggable.

I've learned a little bit more about C# on webassembly.  What I understand Blazor does is that there's basically a webassembly version of an IL interpreter.   So C# assemblies are directly consumed by this interpreter.  C# is not compiled down into webassembly yet.  Still that might work.  It may not be the most natural language for this though.  Go and Rust are still in the running.  I'm obviously already ready for Non-Web Embedding, but I'm not sure what's been done for this so far.