With the desktop application model in development we are finally nearing the stage where we can bring out the big guns and tie the web-desktop infrastructure together. If you are new to QTX you might be wondering what that means? Well, let’s do a little recap of what we are building here and why!
Before QTX existed I had a similar product called Smart Mobile Studio, and I used that to create a prototype of a web based desktop system. Sadly my work on Smart Mobile Studio came to a halt in late 2018, and it became clear that if we finished the desktop system using that compiler, anyone interested in the web desktop would have to buy Smart Pascal in order to work with the codebase I was creating. That made little sense since I had left the company and held no stocks there (I would effectively be doing their work for free, lining their pockets by proxy). At the same time the Smart Pascal RTL would need so many changes to cope, that it would practically be a full re-implementation.
After much consideration we (the backers and myself) decided it would be better to implement a whole new development tool-chain from scratch, and then continue on the desktop project once QTX had matured.
But why a web desktop you might ask? Why would that even be remotely interesting? Well if you have a NAS (network active storage) or a router in your home (chances are you have at least a router) and look at how those devices are controlled, you will find they are both accessed purely through a browser. It also turns out that writing applications for an established NAS brand, such as Synology, is both costly for the developer (absurd developer license fees) and extremely esoteric.
What does such a NAS consist of? Is it black-magic? Does these devices have some secret sauce that separates it from a run-of-the-mill desktop PC? Turns out there is no secret sauce except for their web desktop system, which allows users to manage and work with their NAS from any webbrowser. What you are paying for in blood when you buy a NAS, is ultimately this web desktop system and the work that has gone into that aspect of the product. Most NAS systems are extremely over-priced considering the hardware you get, and you have ZERO control beyond what Synology (or any of the other vendors) gives you.
This is where the Quartex Media Desktop (codename Amibian.js) comes in. A system written 100% in Quartex Pascal and that needs only node.js and a browser to deliver the goods. The entire system is 100% node.js / HTML5, and can thus be moved between architectures ( x86, ARM, Risc-V, PPC ) without needing to re-compile anything.
This work stopped in late 2019 when we had more or less exhausted the old development system (SMS was designed for mobile apps, not a full desktop environment and back-end services). Sadly, COVID took center stage for a couple of years and took a huge bite out of our TTM. I have kept on working on QTX, even though the tasks seemed endless sometimes. But finally, finally we are reaching that sweet spot where the underlying code is evolved enough that we can continue.
Which is where we are now!
Let’s get the filesystem going
People often ask me why I mention the Commodore Amiga in the same breath as QTX, and you would be forgiven for thinking that it’s just a bad case of nostalgia. And while I have many fond memories of learning to code on Commodore machines way back in the early 1980s, this is ultimately not why I find that machine and OS so inspiring.
Commodore was way ahead of it’s time, and many of the ideas that went into their operating system, were quite frankly too complex for the hardware to fully realize. You have to keep in mind that a stock Amiga 1200 had a 68020 CPU running at 14 MHz with 2 megabytes of ram. Your wristwatch (if you have a modern smart-watch like Samsung Galaxy or Apple Watch) has 100 times more processing power than that old machine. However, the ideas and solutions they came up with is where my focus is.
Take something simple, like the filesystem. Amiga OS had a driver based filesystem long before Windows was capable of displaying more than 16 colors. They also organized that filesystem and path structure, so that creating virtual drives was intrinsic to the system. You could in fact mount a folder as a drive by assigning a drive identifier to it, using a simple shell command, such as:
Assign MyDrive: MyFiles/MoreFiles
The above would register a “fake” disk called “MyDrive” that would simply be mapped to the local folder MyFiles/MoreFiles. In today’s jargon this would be called a symbolic link, and you can do this with Windows, MacOS and Linux. But out of those three systems, only Linux comes close to the same ease of use and elegance of the original Amiga OS.
If we take that concept and refactor it to 2023, taking account for cloud storage and the various storage mechanisms popular vendors (such as Amazon, Dropbox or Azure) provide, the path-syntax that Amiga OS operated with makes much more sense than it did running on slow and bulky 1980’s consumer hardware:
Assign MyPictures: Dropbox:pictures
Assign MyMovies: Azure:Movies
The path syntax that Amiga OS operated with is brilliant in it’s simplicity, and the fact that it was driver based both for the physical-media-filesystem and networking filesystems, is one of the reasons Amiga OS is still being used today by thousands of people around the world. Whenever there is a new storage media or protocol, someone writes a driver for it, and the core OS can instantly use the new technology. The path syntax the OS follows is:
[drive|assign|pipe|rexx|samba channel]:folder/folder/fileAs you can see from above, the same syntax covers not just files and folders, but also pipes, samba shares (network shared folders) and rexx. While I don’t see any point of rexx in 2023, the syntax is malleable enough to cover local storage devices, yet it can stretch to also cover networking and IPC mechanisms. Commodore took the best from Unix and DOS when they designed this. They also applied some ideas from an earlier system called Minix. The takeaway here should be, that it’s a formula that has stood the test of time (almost 40 years of continuous use).
In order for us to use this system for our desktop, the same path syntax must be understood by both back-end (services) and front-end (web desktop client). Which means we need a path parser that is able to read, parse and translate an Amiga path, into a Windows, Unix or Linux path. Since Linux is my goto OS for embedded hardware I have focused on that first. With the exception of the drive-moniker (e.g “MyDrive:”), the paths are compatible with Linux and Unix out of the box.
So right now I am implementing the missing pieces so that we can start using and writing node.js back-end services that makes full use of the filesystem drivers. The old system used a hybrid websocket server, which is a normal HTTP/S server that can also deal with websocket connections. This was something I implemented especially for our desktop using Smart Pascal first, but it needs to be refactored for QTX. Which is what I’m looking at now.
The filesystem service and drivers is also something you can use in your applications. In order for it to work properly it requires a second service, the authentication service. Both use the same hybrid node.js server class – so once that is in place, both these node.js services can be used by your programs. Regardless of you using the desktop ecosystem or not.
This is what I love about OOP, namely that we focus on widgets (components), packages and classes. And if you write the classes to be as system agnostic as possible – you can recycle the technology in a myriad of different scenarios.
Deploying large web applications
Another use case for the desktop system, is to simplify how you deploy your large web applications written in QTX. How would you go about implementing a full accounting system for web? You would need windowing (preferably), you will need file-access, you will need database access, you will need strong authentication — in short, you would end up creating the exact same technology!
The web desktop does all of this for you. Once complete you will be able to fork the entire desktop, mold it as you see fit, and use it as a ramp for that large, 60 form application that would otherwise be a mess if you implemented it as a vanilla website.
Writing Client & Server software should be fun!