The Internet Operating Environment (IOE) is a proof-of-concept implementation of a protocol for treating independently distributed JavaScript programs as interoperable applications within a common execution environment.
The broader concept and motivation are described in the 'IOE proposal article'.
This document takes a more practical approach: instead of merely describing the protocol, it implements its components step by step through small executable examples.
Each example introduces a specific part of the protocol and can be executed directly from this document, making the page simultaneously a tutorial, technical reference, and proof of concept.
The initial implementation is intentionally small. Its purpose is not to create a complete operating system, but to demonstrate how applications, dependencies, interfaces, and execution environments can be standardized independently of the particular user interface used to run them.
We begin with a minimal IOE environment. The environment is responsible for providing the facilities through which applications can operate. It is not itself the application.
HTML Document
|
v
+---------------------------+
| Internet Operating |
| Environment |
| |
| Application Loader |
| Interface |
| Application Management |
+---------------------------+
|
v
Application
The first implementation will intentionally be very small. There is no attempt to create a complete operating system or desktop environment. The objective is to demonstrate the protocol with the smallest practical implementation.
An IOE application is an independently implemented JavaScript program that follows the interface defined by the IOE protocol.
The application should not need to know how the surrounding environment is implemented. In particular, an application should describe what resources or interfaces it requires rather than directly depending on a particular graphical or terminal implementation.
Application
|
| "I require a text interface."
v
IOE Protocol
|
v
Environment provides the interface
Before executing an application, the environment needs information about it. The first prototype will therefore give every IOE application a protocol header.
The header will describe information such as the application's name, version, required interfaces, optional interfaces, dependencies, and, when applicable, graphical window requirements.
For the first prototype, the header will be represented by a JavaScript module returning a JavaScript object. This keeps the application self-contained while retaining a structure that can later be represented as JSON or another machine-readable format.
export const IOE_Application =
{
header:
{
name: 'Hello World',
version: '0.1',
interface:
{
required:
[
'text'
]
},
dependencies:
[
]
},
run: function(a, b) { return('Hello World! a + b = ' + (a + b)); }
};
The protocol will distinguish between an application's requirements and the implementation used to satisfy those requirements.
For example, a program may require a text interface without requiring a specific terminal emulator. Another program may require a graphical window without requiring X11, Wayland, SDL, Canvas, or any other particular window system.
Application
|
| requires: WINDOW
v
IOE Interface
|
+-------------------+
| |
v v
HTML Canvas Native Window
This separation is important because the same application should be capable of operating under different implementations of the IOE environment.
The first application will be a simple "Hello World" program that uses the text interface.
The purpose is analogous to a conventional command-line program: it does
not request a graphical window merely to print text. An IOE implementation
could provide this interface using an ordinary HTML element, such as a
<span>, while another implementation could display the
same output in a terminal, console, or native text interface.
IOE Application
|
v
TEXT API
|
+-------- HTML <span>
|
+-------- TUI
|
+-------- Native terminal
Later examples will demonstrate applications that require a graphical window.
Such an application will declare its graphical requirements through the protocol. It may also describe the desired configuration of its window, such as its dimensions, title, and whether it can be resized.
{
interface:
{
required: ['window']
},
window:
{
width: 640,
height: 480,
resizable: true
}
}
The application does not need to determine how this window is created. An IOE implementation could use an HTML Canvas, another HTML element, a native window system, SDL, or another suitable mechanism.
The protocol will also allow applications to declare dependencies. This provides a way for independently developed JavaScript libraries and headers to become components of an IOE application.
For example, an IOE application could use a library from my 'JSHeaders' directory while simultaneously depending on IOE-specific functionality.
IOE Application
|
+---- IOE Includes
|
+---- JSHeaders
| |
| +---- ysxColor
| +---- ysxDraw
| +---- ysxGeoPlot
|
+---- Application Code
This will allow the proof of concept to demonstrate not only application execution, but also the possibility of a distributed ecosystem in which independently maintained components can be combined.
The complete process can therefore be summarized as follows:
1. Locate an application
|
v
2. Load its protocol information
|
v
3. Read the application header
|
v
4. Determine its requirements
|
v
5. Compare requirements with
the capabilities of the environment
|
v
6. Load the application
|
v
7. Initialize the application
|
v
8. Provide its requested interfaces
|
v
9. Application executes
This sequence will be implemented incrementally. Each step will first be demonstrated independently before additional functionality is introduced.
The first experiment will therefore be intentionally simple:
IOE Environment
|
v
Application Loader
|
v
HelloWorld.js
|
+---- IOE_Application
|
+---- Application
|
v
Text Interface
|
v
"Hello, World!"
Once this minimal system is operational, subsequent examples can extend the same protocol with graphical interfaces, dependencies, remote applications, window configuration, and other capabilities.
The goal is to keep every step small enough that the implementation remains understandable while progressively demonstrating the capabilities of the Internet Operating Environment.
We can now begin implementing the protocol with the simplest possible application: the Hello World application.
An IOE application first provides a header describing itself. In this example, the header is provided by the module:
IOE_Application.
The module is part of the application itself and is therefore not manually written into this document. Neither the IOE loader needs to know the name of the application, only the URL.
The IOE environment calls the application's header function and receives the following information:
As this application is intentionally simple, its header declares only its name, version, and required interface. It has no dependencies and requires only a text interface.
The IOE parser receives the returned header and verifies that the application provides the information required by the protocol.
The parser identifies that the application requires a text interface. The IOE environment can therefore route the application's output to a text interface provided by the host environment.
The application also accepts two input values, a and b. Change their values below and execute the application.
For this proof of concept, the text interface is represented by an HTML <span> element:
<span id="SpanTerminal"></span>
The element itself is supplied by the environment. The 'Hello World' application does not directly manipulate it.
Application output:
####### BEG TERMINAL #######
####### END TERMINAL #######
The text displayed above is produced by the Hello World application. It is not directly written into this document.