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).
Monday, April 13, 2020
Sunday, April 5, 2020
2020 Has Eaten My Brains...
Wow. I've had a busy several months. I think about this project quite a lot, but have had little time. The SF conventions that I normally spend coding on this stuff have been cancelled. Alas Norwescon...
Getting the First Person framework working on the loading deck. I've got the VR integrated, but needing to get all the movement stuff working. Unity is having problems with the SteamVR plugin with some of it's more recent versions. I'm trying to run on 2019.3, but still have to remove several of the integration methods to get it to compile. I'm going to try to get teleport movement working. Supposedly Valve is going to write a new version of steamVR (or OpenVR--not exactly sure). This might limit me to the 2019 version of unity for a while. I think--rereading all this and updates, that I need to start using the XR framework.
Keeping an eye on Wasmtime. They're doing good work there. There's a new nuget preview. It looks like if you look in the sources though that they're changing and simplifying the calling structure. It looks like there's going to be a much easier way to integrate the private APIs I need to expose to it via private WASI. You can just call a method to define a function. So I can start getting together some classes to autogen the APIs. It also lets me define different APIs and only load the ones that are appropriate (entities, avatars, and worlds likely have variations in what APIs are present). And eventually will start to implement the standard WASI interfaces that are appropriate (like file IO, but only to the sandboxed and read-only emissary filesystem). It's still looking like Rust for the first language for doing Emissaries, though I need to see how other systems are working. Blazor is going nicely in the dotnet/c# world, but it works rather differently -- There's a CLR interpreter running in webassembly -- I might look into this and see if this is sufficiently well documented to write my own CLR classes for it or if I'll need my own webassembly module (it may be assuming a DOM and other non-embedded things--though eventually, it might be worthwhile having a working DOM).
In the just-fun category, I had an interesting idea. Someone has an actual firmware VT100 emulator running on a virtual javascript 8080 cpu. This is not what is conventionally known as a "vt100 emulator". This truly is running the rom code from a vt100. It was be possible to build one of these into an emissary (I see some 8080 emulators in rust). I was originally thing that these emulators would run server-side and expose themselves in the VR environment via a pseudo-serial connection. So, it would be truly interesting to do this with the other SIMH emulators and Mame and libretro. These are mostly in C, it might be possible to get them into webassembly. Mame has some other VT emulators built into them as well as the million other things Mame can do. I hear rumors that there's an SDL layer that's been ported to webassembly (though probably for a DOM Canvas, but I can probably map that onto a texture).
Next big effort too is to get the various multi-process servers to bidirectionally ping each other and shut down when the browser exits. There a ping that occurs the when the service comes up to indicate that it's ready. I also had the thought to have some kind of indicator of presence and health on the loading deck, like a luminous sphere for each server. Color could indicate load or CPU %. It was a bit of an epiphany that I could start having simple emissaries that don't really require an external entity server, and can show them onto the loading deck. Getting all of the pieces together for loading external content is still a ways off. The initial avatar won't really need any emissaries, until we want to start showing a second-person view. Though we might eventually show hands and such in first-player view--though that might be initially hardcoded and rely on what is available in SteamVr.
I had a sketch of the necessary emissary APIs, so I will also start fleshing those out. Those need some practical hammering so we can come up with some nice coherent architecture for that. Mostly it allows the emissary to manipulate the 3d object which it controls (via hopefully the new Entity framework in Unity). There has to be a bidirectional message pump between the browser process and the emissaries--the emissary requests a change and the data gets passed to the browser and implemented (or it requests a callback to return info back to the emissary). I need to see how GRPC has progressed in the last few months. Perhaps the windows GRPC via named pipe has been implemented in .NET and we can have very fast communication for these message loops.
I'm also seeing lots of nice API documentation on github. Need to work on that for the new code.
Found a Named Pipe implementation for GRPC.
Getting the First Person framework working on the loading deck. I've got the VR integrated, but needing to get all the movement stuff working. Unity is having problems with the SteamVR plugin with some of it's more recent versions. I'm trying to run on 2019.3, but still have to remove several of the integration methods to get it to compile. I'm going to try to get teleport movement working. Supposedly Valve is going to write a new version of steamVR (or OpenVR--not exactly sure). This might limit me to the 2019 version of unity for a while. I think--rereading all this and updates, that I need to start using the XR framework.
Keeping an eye on Wasmtime. They're doing good work there. There's a new nuget preview. It looks like if you look in the sources though that they're changing and simplifying the calling structure. It looks like there's going to be a much easier way to integrate the private APIs I need to expose to it via private WASI. You can just call a method to define a function. So I can start getting together some classes to autogen the APIs. It also lets me define different APIs and only load the ones that are appropriate (entities, avatars, and worlds likely have variations in what APIs are present). And eventually will start to implement the standard WASI interfaces that are appropriate (like file IO, but only to the sandboxed and read-only emissary filesystem). It's still looking like Rust for the first language for doing Emissaries, though I need to see how other systems are working. Blazor is going nicely in the dotnet/c# world, but it works rather differently -- There's a CLR interpreter running in webassembly -- I might look into this and see if this is sufficiently well documented to write my own CLR classes for it or if I'll need my own webassembly module (it may be assuming a DOM and other non-embedded things--though eventually, it might be worthwhile having a working DOM).
In the just-fun category, I had an interesting idea. Someone has an actual firmware VT100 emulator running on a virtual javascript 8080 cpu. This is not what is conventionally known as a "vt100 emulator". This truly is running the rom code from a vt100. It was be possible to build one of these into an emissary (I see some 8080 emulators in rust). I was originally thing that these emulators would run server-side and expose themselves in the VR environment via a pseudo-serial connection. So, it would be truly interesting to do this with the other SIMH emulators and Mame and libretro. These are mostly in C, it might be possible to get them into webassembly. Mame has some other VT emulators built into them as well as the million other things Mame can do. I hear rumors that there's an SDL layer that's been ported to webassembly (though probably for a DOM Canvas, but I can probably map that onto a texture).
Next big effort too is to get the various multi-process servers to bidirectionally ping each other and shut down when the browser exits. There a ping that occurs the when the service comes up to indicate that it's ready. I also had the thought to have some kind of indicator of presence and health on the loading deck, like a luminous sphere for each server. Color could indicate load or CPU %. It was a bit of an epiphany that I could start having simple emissaries that don't really require an external entity server, and can show them onto the loading deck. Getting all of the pieces together for loading external content is still a ways off. The initial avatar won't really need any emissaries, until we want to start showing a second-person view. Though we might eventually show hands and such in first-player view--though that might be initially hardcoded and rely on what is available in SteamVr.
I had a sketch of the necessary emissary APIs, so I will also start fleshing those out. Those need some practical hammering so we can come up with some nice coherent architecture for that. Mostly it allows the emissary to manipulate the 3d object which it controls (via hopefully the new Entity framework in Unity). There has to be a bidirectional message pump between the browser process and the emissaries--the emissary requests a change and the data gets passed to the browser and implemented (or it requests a callback to return info back to the emissary). I need to see how GRPC has progressed in the last few months. Perhaps the windows GRPC via named pipe has been implemented in .NET and we can have very fast communication for these message loops.
I'm also seeing lots of nice API documentation on github. Need to work on that for the new code.
Found a Named Pipe implementation for GRPC.
Thursday, January 23, 2020
Progress with WasmTime
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).
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).
Wednesday, December 18, 2019
WebAssembly and Blockchain Happenings
I am jazzed by the appearance of CraneLift and WASMTime.
CraneLift is a JIT webassembly compiler, and WASMTime, which is a complete sandboxed environment. However, it appears to be for Non-Web Embedding. Which is what I've been waiting for.
CraneLift will probably be the basis of our toolchain.
There's also a nuget module for WASMTime that can be called from .net (though I might have to change all my external modules back again to the latest .net core rather than framework 4.8). This might be much simpler than trying to run V8 (via Microsoft ClearScript) -- and much more portable. I also don't feel any great loss from the not having a Javascript environment.
There apparently is a gRPC/protobuf implementation now for Rust (if the first emissaries need to be written in Rust).
I'm making slow (very-slow) steady progress with the Emissary managers. The browser launches them and they start to do their startup handshakes. However, the next steps, which is mostly being able to log into the various Kudo Servers is going to take some effort. I have the stubs of the new Kudo Authentication engine started.
CraneLift might also let me build server side emissary modules.
I guess I'm going to have to learn Rust after all.
Starting to look at blockchain infrastructure like Corda. The true functioning of the Kudo server is basically a blockchain engine, or at least what it does would benefit from a blockchain journal. A true Kudo (like a game level or a certification) would benefit from blockchain auditing. Nothing much more useless than a blockchain which has an audience of one (like a stand alone system). It's only benefit is being shared far and wide.
I don't think Corda is .net (may be Java/Kotlin). But, it dockerizable, and has an API we can call.
CraneLift is a JIT webassembly compiler, and WASMTime, which is a complete sandboxed environment. However, it appears to be for Non-Web Embedding. Which is what I've been waiting for.
CraneLift will probably be the basis of our toolchain.
There's also a nuget module for WASMTime that can be called from .net (though I might have to change all my external modules back again to the latest .net core rather than framework 4.8). This might be much simpler than trying to run V8 (via Microsoft ClearScript) -- and much more portable. I also don't feel any great loss from the not having a Javascript environment.
There apparently is a gRPC/protobuf implementation now for Rust (if the first emissaries need to be written in Rust).
I'm making slow (very-slow) steady progress with the Emissary managers. The browser launches them and they start to do their startup handshakes. However, the next steps, which is mostly being able to log into the various Kudo Servers is going to take some effort. I have the stubs of the new Kudo Authentication engine started.
CraneLift might also let me build server side emissary modules.
I guess I'm going to have to learn Rust after all.
Starting to look at blockchain infrastructure like Corda. The true functioning of the Kudo server is basically a blockchain engine, or at least what it does would benefit from a blockchain journal. A true Kudo (like a game level or a certification) would benefit from blockchain auditing. Nothing much more useless than a blockchain which has an audience of one (like a stand alone system). It's only benefit is being shared far and wide.
I don't think Corda is .net (may be Java/Kotlin). But, it dockerizable, and has an API we can call.
Monday, November 11, 2019
Considering IdentityServer4
Got a bit of organizational work done over the weekend at Orycon. I'm mostly trying to map out the intra-browser communications via GRPC. The browser can start up and launch it's Emissary processes.
I'm seriously considering making IdentityServer4 a big part of the Kudo server since it seems to overlap with what it was supposed to do. There's still a lot to the Kudo server separate from authorization/authentication, but this seems to be a big chunk I don't have to write.
I'm seriously considering making IdentityServer4 a big part of the Kudo server since it seems to overlap with what it was supposed to do. There's still a lot to the Kudo server separate from authorization/authentication, but this seems to be a big chunk I don't have to write.
Tuesday, October 22, 2019
Embryonic Browser Starting
I'm getting the basic browser put together. Getting all of the thread managers for the Emissary controller projects. I think I've got the gRPC set up on the browser (on the Unity side, this is the hard part). I'll get the basics together to launch the basic processes and get a two-way ping going so the Emissary Processes can die when the browser stops (or they'll just pile up).
I think I've even got a good handle on initial security. I am only doing HTTP/2 on localhost. I'm not planning on other security yet. The browser will generate a random token which it will pass to its child processes in the environment (not the command line). That should keep other users from attacking the processes.
Having emissaries and other such things running on servers will have to wait until we have basically a VRWorlds server running on each machine in the cluster -- but I am planning the ability to have a browser cluster.
I think I've even got a good handle on initial security. I am only doing HTTP/2 on localhost. I'm not planning on other security yet. The browser will generate a random token which it will pass to its child processes in the environment (not the command line). That should keep other users from attacking the processes.
Having emissaries and other such things running on servers will have to wait until we have basically a VRWorlds server running on each machine in the cluster -- but I am planning the ability to have a browser cluster.
 |
| Initial Sketch of the Loading Area |
Tuesday, September 17, 2019
Interfaces Defined
Not much progress in the last week or two. My trip to Bubonicon though I managed to do a pretty creditable list of all the initial APIs. So, I'll be putting this into a document and beginning the effort of defining all of the gRPC definitions for them.
I'm looking forward to having enough pieces to get the prototype browser working, with multiple processes and the ability to load in a working emissary.
In the meantime I've been deep-learning kubernetes by putting a large bit of my own production into docker, and porting some python from v2 to v3.
I'm looking forward to having enough pieces to get the prototype browser working, with multiple processes and the ability to load in a working emissary.
In the meantime I've been deep-learning kubernetes by putting a large bit of my own production into docker, and porting some python from v2 to v3.
Subscribe to:
Posts (Atom)