Converted document

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.

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 (for storing data),
the code space (for storing instructions),
web processors,
web I/O devices.

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

name is a human-readable name of the action (a code pointer), e.g.,
```
uploadFile
```
entry point is a URI-like string representing how to call the action and where to find the corresponding code, e.g.,
```
staticjava:org.webappos.webcalls.FSActions_webcalls#uploadFileToCurrentProject
```
The part before the colon (the protocol part), ‘‘staticjava’’ in our case, denotes the name of a web calls adapter that shall be used to invoke the code. The remaining part specifies the adapter-specific code location (the Java class and the static Java function in our case).

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:

webmemcall 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.