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.

Browser Construction

I'm starting to make a push now to actually get a browser foundation started.  My current issue is .net frameworks.   My common libraries, and gRPC schema libraries are all built in .NET Standard, but to my knowledge now, there are no such versions of ClearScript, which I'm relying on for my V8 embedding. 

So, experimenting, I set the browser compatibility to .NET Standard 2.0, the thing starts up (after doing lots up updates to unity and the packages), with ClearScript installed with NuGet--even though it's a .NET 4.5 assembly--and I'm not yet instantiating the thing or doing anything with the V8 engine.   That's probably next.  Plan is to make a nice generic interface which the libraries can call to get attached to the V8 (which should be done rather formally to assure security and robustness -- and lets me change out the V8 module as needed).

Though, I've been thinking again.  That's the trouble with not hitting "publish".   I was looking at how the Chrome browser talks to itself across it's different processes...  It does it via their own IPC via named-pipes.  I was wondering how easy this would be with gRPC.  Maybe I can just have my own C# executable running there communicating this way.  It would help with scaleout really well.  Anyway, continuing experiments building a browser foundation.