Friends! Let us rejoice for we are nearing the Glory of Decentralization with each and every day!
Now, on Twitter you might had read about us improving various aspects related to the Decentralized Terminal Interface. Let us face it. Implementation of a full-blown Linux, bash-like interface, with various fancy features such as views’ support, toggling back and forth through the history of commands (often multi-line), while at the same time allowing for the lines above to be updated asynchronously, then with colors’ support and stuff turned out to involve way more corner case scenarios than we initially envisioned.
Still, let us rejoice!
Improvements made to the Decentralized Terminal Interface.
On the video above you might see that Wizards ~they are who they are not without a reason.
Implementation of extremely fancy animations in User Interface within a web-browser would have taken much less development time than what you’re seeing above. That’s due to a variety of reasons, including the need to maintain asynchronicity between a variety of events, the need to maintain custom View-Model support, with constant synchronization between the two and the fact that under the hood the only thing which you’ve got at your disposal are ANSI sequence codes from DOS era.
Then, one needs to keep using these for everything. Including caret traversals, hiding / unhiding of the carret, one has to figure out how to handle a plethora of corner-case scenarios if one wills to support more exotic cases and GRIDNET-OS is filled with the support of these. Not a single character is shown in screen without it making a roundtrip from user’s computer to the full-node, making its way to the DTI’s view model which decides what to do with it, and only then a rendering, if any is delivered back to the user.
In short, as you can see by accessing the Test-Net -Wizards got the Job done right. There might be some glitches left but all in all the stability of all of the mechanics is extremely solid, which is of a paramount importance considering the system makes the Terminal Interface available to thousands of users daily/hourly and the functionality is handled by nothing else but the very full-nodes themselves.
Would there be any problem i.e. a potential deadlock situation within the DTI, the entire full-node might become unstable. Our boys always had employed employed military-class code quality requirements (something they’ve got good experience with), thus here it is, nice and easy.
If we’ve got the extremely fancy, animated UI in place why do we keep investing into the DTI? Simple – it’s very close to internal processing of the Decentralized State Machine. We don’t need to waste time designing UI elements just for the purposes of testing, whereas the UI takes use of everything available from within of the DTI directly or indirectly anyway.
Good example of that kind of attitude is the Crypto-snake game. It benefits everyone. Users might begin getting small portions of cryptocurrency while having fun, while under-the hood some of the most advanced mechanics related to cryptography are being tested and brought into play. It also tests some of the most advanced mechanics related to terminal interface and inter-terminal communication (not the Multiplayer mode) which all further and further aids tightening on testing of the overall stability – which so far looks awesome.
The very same mechanics the game employs, the codes one keeps getting when playing, the same (in various flavors, more on that later) will be used to reward intermediaries of data exchange and storage. These are quite innovative things, parts of our latest research to be found nowhere else.
CodesInChaos will have more for you soon.
Yours,
The Old Wizard 🧙.
