That Unbelievable Pipe Dream Thingamajiggy is Working As Prototype
It turns out it was the Golden Grail. It is working.
It all started when I was still in Australia and they put a weird proposition to me … my server should be a dirt cheap transmission of applications to soldiers in addition to delivering web resources. It was an absolute moonshot idea and I encouraged these wild schemes of feature creep by becoming immediately obsessed with the idea of being this super atomic badass who would be revered by soldiers worldwide as the guy who brought the unified field theory of central command and control to every soldier in the arena of combat. Soldiers worldwide would look down on the powerglove on their wrist in the middle of terrible battles and they would think of my name in association with it.
Only a madman would have approved of the feature creep being added to what they already insisted I deliver. I was fascinated by the idea and have been thinking about it in my sleep. I have thought about it when outdoors walking, when sitting, whenever I had a moment to consider it. I developed the conviction I could make this thing work. I knew I could. If it worked, I could do away with the notion of “separate processes” controlled by the server and booted when it started up. There would only be the same process as a new instance which would connect to the server and get it’s interface to tell it what to do and how to behave. One ring to rule them all. I knew it was what I have been working towards for 25 years. Once I got the ASN.1 message format to work correctly and integrated it as a rapidly evolving part of my production chain, I knew I could get the rest working, too.
This powerglove would be the device that was envisioned in FALLOUT by interplay. It would have access to the central server in the same ways a web browser did with a web socket and the entire API made available as ASN.1 binary packets zipping around at the speed of network signals. Everything would be unified in one encapsulating paradigm and the military that used my servers and gloves would never again waste any time with a hodgepodge of third party products or vastly disparate systems. There would only be servers and local processes as a single execution unit. Nothing else to maintain.
Need an inventory manager for your local unit or at the squad level? We’d send it to you. The glove itself could even cache or use local data store to keep the application for as long as you needed it. You’d get automatic upgrades without even knowing it and any data could be verified or shared with anybody authorized. Need to configure Modbus, CANBus or your generator? You’d request the interface application.
Between web browsers and local/remote processes, you’d have a central enterprise that would be shockingly easy to plug-n-play. Literally the Etch-A-Sketch of fallout shelter control systems.
The graphic drivers are really well abstracted from the implementation. The screen shot above is connected to SDL2 with only a half dozen calls to the underlying system to paint the graphics and support audio. This will eventually be streamlined in the compile to a single #define that will switch to text consoles, VT-100 terminals or gigantic graphic displays with touchscreens.
I envision this once it is polished as walking through your shelter with a PIP-BOY strapped on and when you pass the hydroponics lab, you get an option on the glove to see an interface for it that does far more than monitor values in a dashboard the way the web server does. You can configure the state automation of the hydroponics lab according to feedback which has been processed from real-time as to when best to pump the nutrients through the pipes, run the heater, turn on the grow lights, etc. and more. When you pass the radio station, it sends you an interface to tune it and listen in. When you approach your pantry, it comes up with an interface for barcoded inventory management. All changes made in these interfaces is reflected when you go back to the command desk and bring up the inventory menu. You can add to your expiration date warnings a checkbox to put it onto the refresh list and print off a shopping report at the browser. You can request a map server and see the entire region in tile maps stored on your local server with no need of a satellite to still be operational.
There are solutions for the web browser to actually edit state diagrams and determine with visual scripting how things behave. I have been planning on using this emergent standard tool since I first started to think about the problem. It may be possible to do all work on functionality everywhere in the shelter in terms of handling the data through state schemas which are themselves designed by the users. The XState format for state machines as a static data description integrates with the tools and even generator code. The Stately editor will be in the administrator tools for VAULT-SYS as a browser app.
That process I spoke about, the CRON manager, is my first working application I am going to design for this. Every server will likely choose to boot that up as a general watchdog and scheduler so it will be an excellent debugging and polishing project to make certain this works correctly end-to-end. This will also make every successive application easier to design for this system and deploy.
I have been integrating the scripting language to be all-encompassing. It runs on the server to construct web pages, it runs on the process engine to handle state-based hardware for SCADA and it is going to be a built-in portable JIT compiled language that runs so fast it is comparable to machine code. It ran this demo from a single ASN.2 message it received through a “Mock” file at startup that was loaded off disk.
It looks like the server in the first draft will run itself and then run configured instances of this process engine. This may be different on other platforms but it will consist of two executables on the Win32 version I am working on now.
I have decided to call this monster QUINTET because it solves so many of the problems I have identified in this system as time-consuming to build, maintain and debug over the years. It will be a symphony of behaviors that reduces most design problems to simply drag-n-drop. There are five parts to the system that enable it as a complete solution :
REST Services in ASN.1 format (same ones used by web pages)
UI Layout & Scripting Logic (delivered in binary messages)
Real-Time response and requests with events
Data frames received from server and other units through parlay
Behavior schemes designed by state diagrams for operation
There are a lot of details of this system I’d like to talk about but I’ve probably covered too much detail already here. There will be a provision from streaming images over IP as RTSP and RTMP or ONVIF protocols so this opens the possibility of communication with audio or video just as you do on your mobile phone, except this will be secure comms with encryption. I just might resort to running a thread to support those functions or at least a coroutine to keep them smooth.
Hope this update helps to encourage people I am busting my rear here trying to get this system working and out to subscribers as soon as I can.
Regards, Tex