Commit 867e96aa authored by Emanuele Aina's avatar Emanuele Aina

web-runtime: Add compatibility with alternative runtimes

Describe requirements and approaches for alternative web runtimes.
Signed-off-by: Emanuele Aina's avatarEmanuele Aina <>
Differential Revision:
parent 972848f2
......@@ -454,6 +454,122 @@ the launcher just instantiates the classes provided by LibBredon
and interprets the custom "hashbang" script format
defined in the [](#application-manager) section.
The Apertis reference implementation of the shared library
is the default provider of the `bredon-0-launcher` virtual package,
see the [Full compatibility] section.
## Compatibility with alternative runtimes
In some cases it may be desirable to use an alternative web engine
for the web runtime, such as Chromium/Blink.
Such replacement can target a different level of compatibility
with the Apertis reference web runtime, aiming for full compatibility
or just aiming for basic integration with the platform.
### Basic integration
A key point of how all web runtimes are expected to work
from the application manager point of view
is that web applications are not special-cased
in any way by the application manager.
The provisions described in the [Bundle contents] section
equally apply to the reference Apertis web runtime
and to alternative web runtimes.
Just like the reference Apertis web runtime,
alternative web runtimes must provide a shared interpreter
which is shipped in the platform filesystem
and that is used to launch the executable scripts
shipped in web applications bundles.
In the case of the reference Apertis web runtime,
the shared launcher is `/usr/bin/bredon-0-launcher`.
Alternative web runtimes not aiming for full compatibility
must use a different name for the executable,
and versioning it to allow for different incompatible versions
of the same web runtime to be installed at the same time
is strongly encouraged, see the [parallel installability guidelines].
The syntax of the executable scripts shipped by web applications
is left to the alternative web runtime implementor
if full compatibility is not desired.
The section about [](#integration-with-the-apertis-platform)
already provides some guidelines for how any web runtime
should interact with the platform:
* web applications must use the [same format][Bundle contents]
as any other Apertis [app-bundle]
to integrate with the [application manager],
if different formats need to be supported
they need to be converted to the Apertis one by the app-store
* cached files must be stored in the directory
pointed by the `$XDG_CACHE_HOME` environment variable,
as specified by the *Data Storage* section
of the [Applications design document].
* audio playback must be routed through PulseAudio
to ensure that the correct policies are applied
as mandated in the [Audio Management document]
* handover of contents to other applications
is handled through the [Didcot service][Inter-App integration (Didcot)]
Other non-mandatory recommendations
if no full compatibility is desired are:
* use of the provisions described in the
[Preferences and persistence document]
is recommended for a consistent handling
of global and application-specific settings
* use of GStreamer is recommended to benefit
by any hardware-specific acceleration plugin
or any license-encumbered plugin
shipped by the platform
* GObject-Introspection is recommended
to automatically bind all the native APIs
provided by the platform
### Full compatibility
Alternative web runtimes may want to be able
to transparently run existing web applications
that target the reference Apertis web runtime.
Due to the complexity of the task,
this kind of full compatibility does not include:
* compatibility for hybrid applications:
hybrid applications will continue to use WebKit/LibBredon
as replacing the whole C ABI of LibBredon and WebKitGTK+
on top of a different engine is not feasible
* compatibility of web features:
different web engines support different subsets
of published W3C standards and recommendations,
and even different versions of the same engine support different subsets,
so the common advice for web developers
of relying only on widespread features and use progressive enhancements
still holds for Apertis web application developers.
Any alternative web runtime that wants
to transparently replace the reference one
must install in the same path
a replacement for the `/usr/bin/bredon-0-launcher` shared launcher
specified in the [Application Manager] section,
which is able to interpret the executable script format
described in the same section.
Only one implementation of the reference runtime
can be installed on the system at any time,
with all the implementations
[declaring `Provides`, `Conflicts` and `Replaces` relations][Replacing whole packages]
on the `bredon-0-launcher` [virtual package]
to let the package manager handle the mutual exclusion conflict.
Those alternative web runtimes must also use GObject-Introspection
to provide access to the native APIs as described
in the [Platform APIs] section.
## Appendix: launchable script example
This is an example of an executable script named `/Applications/com.example.AddressBook/bin/run`
......@@ -480,6 +596,7 @@ Resources=;;
[Security between applications]:
[UI customisation document]:
[content hand-over]:
[parallel installability guidelines]:
[Application Bundle Specification]:
[graphical program]:
......@@ -488,3 +605,5 @@ Resources=;;
[AppArmor profile]:
[generic resource data]:
[Audio Management document]:
[Replacing whole packages]:
[virtual package]:
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment