The Application Loading Process

The high level steps of the app loading process are:

Loading/Creating the App RW HDF5 Filesystem

All Applications will need a RW Filesystem, even if its just for Hermes to store data about the application. The Process of loading the application is actually the process of creating or validating the RW Filesystem.

Initially the Applications RW HDF5 Filesystem looks like this:

Name	Type	Description	Writable	Required
/		Root Directory
/tmp		Temporary Files stored in memory
/etc		Writable settings

The Application is at this stage un-configured. Once the user has configured the Application, the following files are created in the Application RW Storage and loading can continue.

Name	Type	Description	Writable	Required
/etc/settings.json		Hermes Engine settings for this application.
/etc/<module-name>/settings.json		Module specific Runtime Configurable Settings

If the Application has requested RW storage, then it is created (and sized accordingly) at:

Name	Type	Description	Writable	Required
/var/		Contains variable data files. (Persistent)

Loading the Application itself

At this stage, the RW Filesystem is now prepared.

HDF5 allows us to create symbolic links between different HDF5 files. We use this capability to create RO symbolic links between the RW filesystem and the Application HDF5 package.

During this process, any files which are defined in /usr/lib which would over-ride the contents of a module are linked inside the module, rather than the original module contents.

This allows us the re-create the view the application sees of itself, without editing the actual application at-all.

During this process symbolic RO links are created for the following files within the Application package:

Name	Type	Description	Writable	Required
/srv		Data which is served by this system.
/srv/www		Files automatically served for this application on HTTP.
/srv/share		Data files which are not automatically served but can be shared by all Wasm Modules in the application.
/usr		Shareable, read-only data.
/usr/lib		Application over-rides for webasm library modules.
/usr/lib/<module-name>		Application over-rides for named webasm library module.
/usr/lib/<module-name>/config.json		Config to use for the module instead of its bundled config.
/usr/lib/<module-name>/share		Overrides for a modules shareable readonly data
/lib		Wasm Component Module Library Directory
/lib/<module-name>/metadata.json		Modules Metadata
/lib/<module-name>/module.wasm		Actual WASM Module
/lib/<module-name>/config.schema.json		Modules Fixed Configuration Schema
/lib/<module-name>/config.json		Modules Fixed Configuration (Must match the schema)
/lib/<module-name>/settings.schema.json		Modules User Settings Schema
/lib/<module-name>/share		Modules shareable readonly data
/lib/<module-name>/author.cose		Modules Author Signature
/metadata.json		Applications Metadata
/author.cose		Application Author Signature
/publisher.cose		Application Publisher Signature

Mounting the /srv/www filesystem in the HTTP gateway

At this stage the Applications /srv/www from the RW Filesystem (as linked to the application package itself) is registered with the HTTP gateway inside the hermes node, and it can begin serving those files.

Loading and Initializing the WASM Modules

The final step is to iterate all the WASM Modules in the RW Filesystem (as linked to the App) and load them in canonical order into the WASM Executor.

This needs to be the final step because when a WASM Module is first loaded, it may be initialized. That process may require access to any of the data or configuration stored within the Application. It is only safe to access that data when the entire RW Filesystem and its cross linked application resources are ready to be accessed.