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.,
-
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:
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):
|
|
Apps, Engines (Libraries), and Services in webAppOS
Apps
A webAppOS application consists of:
-
A set of actions (from the code space).
-
Some configuration, which (among other settings) instructs how a web app has to be delivered to the end user (refer to the app.properties file format). For instance, an app can be delivered as static HTML/JS/CSS files, as a PHP application, as a Java servlet, etc. To support various delivery methods, webAppOS relies on app adapters (specified via the app_type property).
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.
-
Since the app will be delivered as HTML/JS/CSS app, we specify the app_type property:
Since ‘‘html’’ is the default type, this property could be omitted. We added it explicitly to show how to specify the app type.
-
Since we do not have any projects created with the Sample app yet, we cannot rely on templates. Thus, when launching an app, webAppOS will create an empty memory slot, which has to be filled with some data; some initial code has to be launched for that. We specify that code in the initial_webcall property, which must follow the tdacall calling conventions (it will be a static Java function bootstrap located in the class org.webappos.apps.sample.SampleApp_webcalls):
initial_webcall=staticjava:org.webappos.apps.sample.SampleApp_webcalls#bootstrap
-
Since we want to display dialog windows in our app, we attach Environment Engine (for displaying the main app window with the default toolbar containing the ‘‘Sign out’’ button) as well as Dialog Engine (for displaying arbitrary dialog windows):
requires_engines=EnvironmentEngine,DialogEngine
-
The default extension of saved projects will be .sample (the lower-cased app name). We can add an icon by storing it as a file with the relative path web-root/application/sample.png. We specify the icon path in the mimes property (the icon path resembles the syntax of MIME types, i.e., without the web-root directory and without the extension; this path will be used as a MIME type for the given extension):
mimes=.sample:application/sample
-
Finally, since some server-side code will be written in Java, we can specify the classpaths property containing the class paths relative to the app directory, delimited by semicolons. We can also specify the lua_paths property for Lua files according to the Lua path syntax. However, since we will place our Java classes into the bin subdirectory and Lua files into the lua subdirectory, the corresponding web calls adapters are aware of these common subdirectory names and will add them automatically.
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.