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.
Showing posts with label Emissary. Show all posts
Showing posts with label Emissary. Show all posts
Sunday, May 3, 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).
Friday, August 16, 2019
API Layers
Cranking up the old Visio again...
Ogres are like onions, because they have lots of layers...
If you see the crazy number of empty projects I've been checking in, you'll see now what I intended. This drawing was also to give myself some more clarity of what I was just randomly creating as I saw a need. Now the thing this doesn't show is what APIs (or parts of APIs) are implemented where. I will work on this part next, so I can start to get a full skeleton of what the API trees are going to need to contain.
I also saw the need as I was writing for a provisioning API (how many servers are where--mostly interacting with the Data Plane and the Orchestration (though their data is stored in etcd). Also most of the server types will initially need a conventional web page for signing up and utilizing. Someday that will all get done in VR. Ultimately there will be some kind of Dashboard -- again someday visualized in VR. For now, I'll find some conventional monitoring tool.
I also like that I've have some good structure happening on the browser. I think that I know how that's supposed to be built. Also, I've mostly figured out out how its Control/Data Plane is going to work (ProtoBufs over Named Pipes--though I wish I could just use gRPC). I also had an amusing idea--no real reason Named Pipes wouldn't work across multiple machines if you want to turbo-charge your browser. Though also should allow conventional sockets so your browser-assist can come from a Linux box. Also probably should consider building a Unity Linux VR browser, so need to be agnostic on this part of the infrastructure. I could make co-processor boxes that you attach to your regular machine.
Anyway. Little steps happening in the background.
Saturday, May 18, 2019
Emissary Builder Prototype Done
I've got the basic emissary builder done in c# in the 3DOM library.
So now, there are a ton of things to do.
So now, there are a ton of things to do.
- Start the browser
- Need skeletons and initial functionality for all server types
- Kudo
- Avatar
- Entity
- World
I need to figure out what rules are for putting Unity projects into github. I know you're not supposed to post Unity code so I've basically got to do it with my own code or with pieces that I download from github, not from unity. I probably need a really good .gitignore file.
So, the next thing will be to get enough pieces together so that I login to a world, and start loading up the world and then I can marshal all of the emissaries as they come down. I have envisioned the hello world state for the browser that materialized an invisible avatar in the middle of a scene with a couple of cubes on a plane with all of the particating servers supplying data.
Onward and upward...
Sunday, May 5, 2019
On Emissaries and Meshes (Idea for Mesh Cache)
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 needed for the Entity to operation. Problem with that is, after the mesh moves from its initial state, that part of the Emissary file now becomes unusable dross, weighing down the file and requiring it to be transferred each time it is cached.
I'm thinking instead, that what is needed is a separate cache database (probably in sqlite) which contains the various meshes in whichever states are needed, and to have a separate way to download them to the browser. Basically, you'd have an Entity Id, the Mesh Id, and probably a state id (which might be simply a incrementing integer, or some other form of version). We need a fast and efficient serialization/deserialization format for meshes. Maybe there's a standard out there.
_payload is likely still useful for other fixed assets, like audio files or jpeg images.
I'm thinking instead, that what is needed is a separate cache database (probably in sqlite) which contains the various meshes in whichever states are needed, and to have a separate way to download them to the browser. Basically, you'd have an Entity Id, the Mesh Id, and probably a state id (which might be simply a incrementing integer, or some other form of version). We need a fast and efficient serialization/deserialization format for meshes. Maybe there's a standard out there.
_payload is likely still useful for other fixed assets, like audio files or jpeg images.
Friday, April 26, 2019
On Meshes
Since most of the life of an emissary is to push reactive changes from the server into the manifestation of the Entity, which is mostly simply a group of meshes, I wanted to make sure there was a robust API for doing mesh manipulation -- somewhat beyond the functionality of Unity itself -- I'm looking hard at G3Sharp. Which seems like an awesome library, and it's Unity compatible.
I need mesh alteration, composition and eventually mesh additive and subtraction operations. So, some of this API will get wrapped and exported into the 3DOM APIs. Also, you can have mesh files in your emissary payload (in several formats, including STL, OBJ), which can get loaded.
This is also part of the tooling projects I'm contemplating, which I'm calling the Wood-Shop tool. I'm not much of a 3d artist, but I can craft pretty fancy 3d stuff in the real world, so I'm trying for a metaphor that's closer to working with wood and metal tools.
I need mesh alteration, composition and eventually mesh additive and subtraction operations. So, some of this API will get wrapped and exported into the 3DOM APIs. Also, you can have mesh files in your emissary payload (in several formats, including STL, OBJ), which can get loaded.
This is also part of the tooling projects I'm contemplating, which I'm calling the Wood-Shop tool. I'm not much of a 3d artist, but I can craft pretty fancy 3d stuff in the real world, so I'm trying for a metaphor that's closer to working with wood and metal tools.
Tuesday, April 23, 2019
More Thoughts on VR Facing Applications
Riffing on that last post about Node/Chrome compatibility. I would so love to be able to bring a fully functioning browser into VR, with an eye to being able to run chrome in Kiosk mode or even a version of Electron to be able to run Code or something like that inside.
However, unless it's amazingly easy to do, it's way down in the list of priorities.
However, I have been thinking of doing something like frame-buffer mapping as part of the emissary functionality. I have my VT100 emulator, and there's a Unity VNC client somewhere (not sure how good it is), but ultimately it would be nice to have something like a X/RDP/Citrix functionality. Also I envision lots of retro emulators, where something like this could expose the screen, possibly with point-audio. Old school games have pretty low resolution, so not so hard. RDP now can connect to one application on the remote side.
I don't know how this works into a virtualization/containerization world. Certainly X works in a container. Don't know enough about windows containers, though perhaps Wine might work too.
However, unless it's amazingly easy to do, it's way down in the list of priorities.
However, I have been thinking of doing something like frame-buffer mapping as part of the emissary functionality. I have my VT100 emulator, and there's a Unity VNC client somewhere (not sure how good it is), but ultimately it would be nice to have something like a X/RDP/Citrix functionality. Also I envision lots of retro emulators, where something like this could expose the screen, possibly with point-audio. Old school games have pretty low resolution, so not so hard. RDP now can connect to one application on the remote side.
I don't know how this works into a virtualization/containerization world. Certainly X works in a container. Don't know enough about windows containers, though perhaps Wine might work too.
Saturday, April 20, 2019
Thoughts on Emissaries and Chrome/Node Compatibility
So, I wasn't really thinking that the V8 environments in the browser would be truly compatible with node or chrome. That leads to issues handling something like NPM compatibility. Though I guess that is just what kinds of compatibility APIs I want to enable. Some chrome compatibility shouldn't be too hard.
I'm wondering if it might be necessary for Emissaries to have dependency chains, and to have the notion of special Emissaries that simply implement libraries, like underscore. Marshaling would then handle the import/export issues. Of course, we don't have a DOM (though we might have a dummy DOM that we could do things with, perhaps even to the point of having a real DOM that could be displayed 2D in the world). I've thought of doing odd things like porting QT (or even something as simple as TCL) to be able to run simple GUIs. Really, supporting real web dialogs would probably be better.
I'm really just one person at this point and have to build in such a way that I can actually make progress, so obviously this is way out-of-scope for now, unless there are simple implementations that I can start with which can render into a texture in Unity. I do need machine dialogs, and am thinking of the concept of an "App", which is a very special entity which is in your Active Inventory, which is something you can have as a HUD, or at least something you can bring up to interact with.
But, once I start writing Emissaries and their 3DOM interactions, I'll likely want a deeper environment than JavaScript, which I so hate -- I'm thinking maybe to do TypeScript instead, though I really would rather do webassembly, which is a bit of a mess right now as far as real Tool-Chains are concerned. I can do C# (maybe), Go (maybe), and certainly Rust.
I have the hello-world, included in the box worlds and entity servers I wanted to build (A Virtual TARDIS), but still a bit up in-the-air as to what what platform I want to build them on. They should be sufficiently standardized that I could build in C#, Go, Rust, Python, Java, or whatever. I'm partial to Python and C# and want to do more with Go. Rust and Java -- probably no. APIs for them? Maybe someday.
I'm wondering if it might be necessary for Emissaries to have dependency chains, and to have the notion of special Emissaries that simply implement libraries, like underscore. Marshaling would then handle the import/export issues. Of course, we don't have a DOM (though we might have a dummy DOM that we could do things with, perhaps even to the point of having a real DOM that could be displayed 2D in the world). I've thought of doing odd things like porting QT (or even something as simple as TCL) to be able to run simple GUIs. Really, supporting real web dialogs would probably be better.
I'm really just one person at this point and have to build in such a way that I can actually make progress, so obviously this is way out-of-scope for now, unless there are simple implementations that I can start with which can render into a texture in Unity. I do need machine dialogs, and am thinking of the concept of an "App", which is a very special entity which is in your Active Inventory, which is something you can have as a HUD, or at least something you can bring up to interact with.
But, once I start writing Emissaries and their 3DOM interactions, I'll likely want a deeper environment than JavaScript, which I so hate -- I'm thinking maybe to do TypeScript instead, though I really would rather do webassembly, which is a bit of a mess right now as far as real Tool-Chains are concerned. I can do C# (maybe), Go (maybe), and certainly Rust.
I have the hello-world, included in the box worlds and entity servers I wanted to build (A Virtual TARDIS), but still a bit up in-the-air as to what what platform I want to build them on. They should be sufficiently standardized that I could build in C#, Go, Rust, Python, Java, or whatever. I'm partial to Python and C# and want to do more with Go. Rust and Java -- probably no. APIs for them? Maybe someday.
Thursday, April 18, 2019
Thoughts on Emissary Structure
Internal form of an Emissary Load File:
This is inspired by Android APK and Java Jar files. But, I think instead of using a zip format, I will use a TAR format. The reason for this is speed. Also, after a possible compression layer is removed, the tar file can be internally seek'ed in order to emulate a high speed filesystem - while this is problematic for compressed files. Since it is the intention of the Emissary file to become a read-only virtual filesystem for V8, this works rather well.
Files at the top level (speculative):
- CERT.CA - Certificate of the code signer
- Manifest - A JSON file containing cryptographic checksums (sha256) of all the files in the module. This should be signed by the above certificate.
- Manifest.sign - the digitally signed version of the sha256 of Manifest
- _code - directory containing the emissary code
- _code/main.js - the startup script
- _code/main.wasm (future) - a webassembly startup
- _payload - the root of the filesystem for the Emissary.
Loading the Emissary is known as Marshaling it.
The system will open this file and inventory it (traverse the 512 byte TAR file headers and build an index) and store the index in a sqlite database. If will check the certificate and load the manifest and check that it's properly signed. Then it will checksum all the files and compare these with the manifest to validate the load. Any errors will cause the Marshal phase to fail.
If the original mime-type comes back as something like GZIP or a compatible compression type, it will be decompressed into a TAR file that is placed in a cache area (compressing these is recommended and may become mandatory, though we may ultimately support different algorithms). That way, it will be available - already marshaled without needing to reload it. However, new software revisions will have different codes and these will be automatically loaded. Theoretically we can do hot code changes this way.
Note on the read-only nature of the Emissary: Besides the security aspect of allowing this to be modified, state is only allowed to be cached on the Emissary side -- we will likely give access to some small database or redis for this. True persisted state exists on the server side, so we don't want to encourage the Emissary to think it owns state. If we need to cache big Emissary-side objects (like big meshes) we'll make a way to do that inside 3DOM.
Subscribe to:
Posts (Atom)