What is ioL?
- ioL: the input/output layer
- A new kind of computing interface
- A software layer between applications and the users, that mediates how users and programs interact.
ioL combines the benefits of both terminal and browser-based computing into a wholly new computing paradigm, and unlocks some new possibilities along the way.
A sneak peek
ioL is so radically new that it isn't easy to explain in a few words. So before getting into the details of what ioL is, here's a concrete example of what ioL can do.
Compare the two screenshots below. The one on the left shows a simple terminal-based game written in Python. It's the kind of program a novice programming student might be expected to write as an exercise. It takes up around 65 lines of Python code (the actual choice of programming language is immaterial as we'll see later), and handles such tasks as prompting the user to select a difficulty level, randomising a number for the user to guess, and keeping score of the player. The program uses no external libraries, excepting part of the standard Python library used for generating random numbers.
This program, though simple, contains a bug of sorts. When prompted to enter a difficulty level at the start of the game, the user might enter an invalid string of characters, crashing the program. Validating against invalid inputs can be a pain, and this 65-line Python program doesn't do it everywhere it should.
ioL breaks all the rules
Now look at the screenshot on the right. Here, the same Python program has now been enhanced to feature a full graphical user interface. You might expect that adding a GUI would make a program more complex internally. But with ioL, the GUI actually makes our program more robust with very little outlay. By graphically limiting user inputs to valid options, the interface now guards the program against being fed invalid inputs.
The program now takes up around 70 lines of Python code (around 5 lines more than previously, but still only slightly longer than a screenful of code on a typical display). The underlying code structure has not been significantly changed, and surprisingly, the program still uses no external libraries. But somehow, it now has a fully functional graphical user interface. This is not a mockup, but a screenshot taken from a working system. How is this possible?
The world's been doing GUIs wrong
Until the mid 1980s, most computing was done using a simple paradigm of input and output through a terminal. When the graphical user interface went mainstream, nobody at the time knew how to make such an interface work with a terminal-based approach, so vendors improvised in ad-hoc ways. The result has been application ecosystems built around transient and non-standard vendor-specific interface libraries. The application must be structured specifically around the latest version of the vendor's platform, and often can only be written in the language specified by the vendor, since it must fit precisely to the runtime library provided. Libraries become obsolete but cannot be improved without the risk of breaking existing applications, and there is little incentive to write quality software around a specific version of a platform that will inevitably change. By contrast, terminal-based applications tend to outlast their more fragile graphical counterparts, remaining usable indefinitely, and even the first website ever made still functions correctly on today's modern web browsers. Today, introductory programming courses eschew GUI libraries in favour of the old-school terminal, and there has been an exodus of professional developers from platform-specific application ecosystems to web development.
ioL is a new approach that delocalises the program's interface from its
implementation. Broadly speaking, ioL is a kind of terminal. In fact, it fools the
operating system into thinking that it is a conventional terminal, so any
application written to run in a terminal can be modified to run graphically in
ioL. But it has one important difference from a conventional terminal.
A conventional terminal window that you might use under a typical operating environment is designed to emulate a historical device known as a Teletype (TTY). Teletypes were glorified electric typewriters first marketed in the 1930s as a means of transmitting text digitally over telegraph lines. Such a device prints characters as it receives them, without interpretation. Therefore it is limited to displaying plain text.
Hello <span italic=true bold=true {world!}>
|
| Hello world! |
ioL is a terminal with a built-in layer of interpretation. Instead of aiming to replicate the capability of a glorified electric typewriter, ioL provides programs with more depth of expression for how they output information. ioL still accepts text output from programs and displays it on the screen, but in addition, ioL also accepts tagged markup instructions within the text, the same way a web browser interprets tagged markup for formatting. ioL's code looks a little like the HTML code that powers the web.
Unlike a web browser's HTML code however, ioL's markup code is Turing complete, which means that additional languages (like Javascript and CSS) are not required within the terminal. Another difference from the web is that ioL is not designed for retrieval of whole fully-formatted pages, but for continuous two-way communications as the user interacts with the program. This kind of conversational approach makes ioL applications a great deal simpler to develop than web applications!
A conventional text-only terminal takes the user's keyboard input and streams it back to the program as typed, so the user is required to manually do the work of formatting and entering input to the terminal exactly as the program expects to receive it. ioL provides a <put> instruction (analogous to the PRINT instruction you find in many programming languages, except operating in the other direction) which, when coupled with event bindings and other ioL constructs, allows a program to specify exactly what input it requires and the circumstances in which to receive it. With a traditional terminal, ouput can only be appended to the display, and old output eventually scrolls off the top of the screen; it cannot be changed after it is printed. In the age of graphical computing, the old approach won't do, so with ioL, elements printed to the screen can afterwards be manipulated as objects and updated as needed. ioL provides typed variables, methods and event bindings allowing the program to process input and dynamically manipulate the interface on the client side.
Where ioL fits in
Let's take a look at the computing interface landscape today. At one extreme is the text-only terminal; an indispensable tool for nontrivial computing tasks, but not usually a tool for the faint-hearted. At the other extreme is browser-based computing. It doesn't integrate so well with the operating environment at the application level, and can be a pain to develop for, but it does at least allow a mechanism for online applications, and avoids the ad-hoc dependency nightmare of conventional GUI applications. A key characteristic of both approaches is the delocalisation of the user interface from the program implementation. Providing an intermediary layer between the program and the user makes programs more robust in general.
| TTY terminal | Browser-based |
|---|---|
| Originally designed for conversational information transfer over telegraph networks | Originally designed for retrieval of whole static pages of information at a time |
| ✓ Simple conversational i/o interface | ✗ Complex HTTP protocol stack based on GET and POST requests |
| ✗ Limited to plain text only | ✓ Applications can express rich text and multimedia content via markup tags |
| ✗ User is expected to manually format and enter input in the required form | ✓ Client-side mechanisms for passive and active input validation |
| ✓ Terminals can be local or remote | – Optimised for remote rather than local clients |
The above 'advantages' and 'disadvantages' apply purely to the problem of interactive interfaces. Some of the web's disadvantages here are in fact the very same things that makes it a fantastic system for its original purpose as a semantic content protocol, but that's not the problem we're discussing here.
ioL provides a middle-ground between these two paradigms, hybridising them into a graphical terminal system. ioL draws on the strengths of each approach to eliminate the weaknesses:
| ioL terminal |
|---|
| ✓ Simple conversational i/o interface |
| ✓ Applications can express rich text and multimedia content via markup tags |
| ✓ Client-side mechanisms for passive and active input validation |
| ✓ Terminals can be local or remote |
ioL solves the age-old developers' conundrum...
Should you develop your application to be run natively on a local machine, or develop an online application to be served remotely?
In today's environment, these would be two very different applications developed in very different ways. With ioL however, the interface is delocalised from the implementation. The result of this is that there is no longer a distinction between a local and online application in terms of how it is developed. The only difference is in how it is deployed.
With a few clicks of a mouse, you'll be able to take a local, native application, and set it up to be served online via a network protocol like SSH. Your computer becomes a server for people to access your application through, in a comparable way to how they might access a web application, with a similar user experience and similar performance, except that the web browser itself is no longer required.
Imagine never having to install a printer driver again
Eventually, ioL will make hardware device drivers obsolete. This is achievable through two mechanisms. One, already discussed, is the ability for a computer program to express its interface in a delocalised way. The other is dynamic piping – the ability for interfaces to exchange information with one another at the user's request.
Command-line terminal-based systems are admired for their flexibility. You can set up a pipe to direct the output from one program into the input of another. But you can only do so in a static way, right when the application is started. For interactive graphical applications, this doesn't go far enough. From the first release, ioL will provide a 'dynamic piping' system, partly inspired by the clipboard system provided in many GUI environments, allowing interfaces to serve as a front end to exchanging data between applications at the user's request.
Modern printers, and other hardware devices, are getting fairly smart. The logic provided by the printer driver you have to install could easily be embedded into the printer hardware itself, but then there would be no way for a typical operating system to interface with it. With ioL, a specially-designed printer, scanner, or any other hardware device can stream its driver interface to the user's machine over a USB cable or network. Nothing needs to be installed, the appliance only needs to be connected for its full capabilities to become available.
Printers are one thing. What about 3D printers? What about hardware devices that haven't been thought of yet? Operating systems have been treating printers and similar hardware devices as a bunch of special cases, which have had to be implemented explicitly by each application, putting a lot of dead weight on hardware innovation over the years. This approach will not remain sustainable. ioL modularises everything so an application that can save data to a filesystem can equally print data to a printer, or even an online printing service, without having to implement it as a special case, or even having to know what a particular hardware device has been designed to be able to do.
There are many more possibilities. ioL has the potential to unlock a lot of possible new directions for the world of computing.
Other highlights
- Powerful graphical and multimedia rendering capabilities, comparable to the rendering capabilities of a modern web browser, backed by our Hipe display server.
- Efficient performance. Super responsive even on low-power devices like the Raspberry Pi.
- Apply a graphical interface to almost anything. At a 2017 weekend hackathon event in Melbourne, the author developed a proof-of-concept graphical user interface embedded within an Ethereum smart contract, potentially enhancing the viability of the booming Ethereum platform with very little overhead. (Learnings from Reghack Downunder [PDF] – page 7.)
What else?
ioL is being developed by Daniel Kos, a computer scientist and physicist based in Melbourne, VIC. A proof-of-concept version of ioL exists, but the terminal language will be streamlined and simplified prior to release. More work is needed, along with additional resources to bring move the project forward and document the system for developers.
The finished product is intended to form a part of a new kind of 'desktop computing console', a computing appliance based on power-efficient commodity hardware. The author has been developing a toolchain for an OS distribution based on ioL with fast startup time and numerous other innovations, providing an intuitive computing experience that is also a radical departure from a lot of mainstream personal computing, and closer to the computers those old sci-fi movies promised you.
The situation with today's GUI application platforms, both on desktop and mobile, closely resembles the fragile state of enterprise computing before the introduction of SQL – an intermediary layer of interpretation for database systems – in the 1990s, enabled more robust and maintainable back-end systems. ioL aims to do for front-end user interfaces what SQL has done for back-end database systems in enterprise.
Take a look inside this directory for the source code of the example programs shown above, as well as additional sample programs and screenshots. Note that you won't be able to run these programs without the ioL terminal system itself (which is not ready for release yet) and the ioL output syntax will be streamlined slightly prior to initial release. Therefore the examples exist for illustrative purposes only.