(in progress)

Introduction

Babbage and Turing assumed that the computer is as a single device operated by a single user executing one program at a time. Such way of thinking is close to the psychology of the human brain: the facts show that the brain is not able to focus on multiple tasks at the same time. Today, when we have multiple connected computers, multiple user accounts, and multitasking, it is difficult to remain in the same simple world, in which Babbage and Turing lived. It would be nice if we could still create web applications by focusing on just one program, one target computer, and one user. Such an illusion is what webAppOS tends to provide, — the illusion of a single target computer for web applications, the web computer. figure brain.png

The Web Computer

The web computer is an abstraction that factors out the network as well as the multi-user and multi-process management. The web computer consists of the following main parts:

Web Memory

In the web computer, due to security issues, memory is split into data memory (called web memory) and instructions memory (code space). Thus, the web computer implements the Harvard architecture. That differs from most classical computers, which follow the von Neumann architecture, where data and instructions are put into the same memory. Notice that although data and the code are separate, references to code (code pointers, which actually are strings) can be stored in the web memory.
Web memory is implemented not as an array, but as a model, which is a graph-like structure (it is more suitable for synchronization as well as for formalization). A model resembles Java OOP-like memory. In webAppOS, a model can contain classes and the corresponding objects (instances). Each class can have attributes, while objects can store the corresponding attribute values. Besides, there can be associations between classes (and the corresponding links between objects). For more detail on models, refer to the excerpt on models and model transformations.

The Code Space

The code space relies on existing programming languages and technologies. From the web computer perspective, the code space is a pool of actions. An action, in essence, is some server-side or client-side function. The term web call is used to denote an action invocation. In some cases it can denote an action definition.
Each action definition is in the form name = entry point,  where
Each action must conform to certain calling conventions, which indicate how the arguments are passed to an action, and how the value is returned. Currently, two calling conventions are supported:
tdacall the argument as an object via web memory, the call is asynchronous without any explicit return value (the return value, however, can be stored somewhere in web memory);
jsoncall the argument and the return value are encoded as JSON objects (stringified in some cases); although the implementation is usually synchronous (returning a JSON), the invocation can be enqueued internally and the result can be wrapped into a promise/future.
Actions are defined in the .webcalls files, where additional modifiers can also be specified. For more detail, refer to the .webcalls file format.
All web calls are invoked in a standardized way, regardless of where the underlying action code is located. Thus, we say that web calls are implementation-agnostic, meaning that even if the implementation of an action is changed (even moved from the server to the client and completely rewritten), all web calls to that action will remain valid as soon as the calling conventions and arguments match both the old and new implementations.

Web Processors

Web processors are software units that are able to invoke code (actions). There is usually one client-side web processor (running in the web browser) and one or more server-side web processors. In some cases, remote web processors (running on remote servers) can be introduced as well.
Like in traditional multi-processor and multi-core systems, developers do not need to think about which particular processor will execute a particular web call. The appropriate server-side, client-side, or remote web processor will be chosen automatically depending on the programming language and the environment required by the given web call. The web processor then invokes the given action via a particular web calls adapter, which takes care or preparing the necessary environment and invoking the web call.

Web I/O Devices

We use the input/output device metaphor to denote data sources and receivers other than web memory. Examples of such devices are the server-side file system and databases as well as external cloud storage. Specific graphical presentations within the browser window as well as client-side devices (such as printers) are also considered web I/O devices.
For some devices (such as the server-side file system and cloud drives), predefined APIs will be defined. Other non-predefined devices can still be accessed from actions implemented in native code.

The Web Computer OS: webAppOS

Developers do not access the web computer directly. They do that via a set of services and APIs provided by the web computer OS, webAppOS. Now you can proceed without diving into numerous technical and implementaion detatails. However, if you wish to do so, then refer to (in the order of increasing detalization):
figure webAppOS-screenshot.png

Apps, Engines (Libraries), and Services in webAppOS

Apps

A webAppOS application consists of:

Projects

When client-side part of an webAppOS app has been delivered to the web browser, it can initialize a web memory instance (or a slot). Either a new empty slot (without any data in the web memory) can be occupied, or a slot with some predefined data can be created from a template. After an app manipulates web memory, its state is saved into a project, which can later be reopened. A project is a zipped folder containing a web memory dump plus some additional app-specific files.

Engines

Certain actions can be factored out into libraries called engines (analogs of DLLs or shared libraries), which can be re-used by different apps. Platform-specific aspects can also be factored out into engines. In this case, the engine will have multiple platform-specific implementations, which all contain a similar set of web calls actions (the target environment will enforce a particular implementation).
To support pure model transformation languages that are unable to make web calls, webAppOS provides the ability to invoke actions by creating a link in the model.

Services

Besides applications, there are also services. A webAppOS service is a module that provides useful functionality to applications but is invisible to end users. Services can be implemented as Java servlets, as client-side JavaScript code, non-HTTP services, etc. Service adapters are used for different service types (refer to the service.properties file format, where the service_type property is defined).

Your First webAppOS App

The app will demonstrate how to write a web app using server-side Lua and Java code. The goal is to store in web memory a counter, whose value would be equal to the number of times the current project has been opened. Each time a project is opened, this value is displayed in a dialog window.

Creating the app configuration

Since apps are located in the apps directory, we will put our Sample app into the apps/Sample.app subdirectory (see the apps/Sample.app directory in the sources tree at GitHub for a ready example). We start by filling the app.properties file inside that directory.
The main app icon should be placed into web-root/icons/Sample-icon.svg (here ‘‘Sample’’ is the full app name). It will be used by the Desktop app and by the client-side webappos.desktop.show_launcher function that can be invoked from any webAppOS app to show the list of the available apps.

Writing the code for the initial web call

The role of the initial web call is to fill web memory with some initial data, to invoke some initial actions, and to specify which web call to invoke later when the project is being opened. Let’s write this code in Java.
TBD.