Introduction

This section defines the functionality of the module loader component of WebVM. This is a utility library to assist in the creation of JavaScript bindings for WebVM libraries as independent JavaScript modules, and to assist web applications load and manage those modules.

Note that the module loader is simply a utility library, and it is possible to access WebVM functionality without it. Developers that already have functionally equivalent libraries can elect not to use the WebVM module loader. However, the loader contains functionality that makes it easier to use WebVM functionality, and can also be used to mask certain browser-specific details in the use of WebVM that otherwise harm cross-browser interoperability of WebVM modules.

Scope

The WebVM module loader provides the following functionality:

• onload event handing: a function allowing modules to register handlers for the onload event, with the implementation ensuring that those handlers are run in appropriate order.

• module loading: functionality to manage the loading of named modules, including:

• resolution of a module name, version and parameter set to a URI;

• handing module load requests, loading if not already loaded

• allowing individual service providers to register a URI factory that handles loading details specific to their libraries;

• triggering installation of WebVM libraries where required;

• dynamic creation and inclusion of webvm-specific markup for use within WebVM modules or web applications, including:

• emitting tag with relevant parameters;

• emitting code hooks for events interface;

• translation of module load parameters into parameters to pass to a WebVM library.

Implementation namespace

The module loader uses webvm.* JavaScript globals.

Module identification/parameterisation

Modules are identified by their id which is a URI. There are no restrictions placed on the form of the URI by the WebVM module loader, but certain functionality is available for URIs that follow a particular form.

Module ids can describe an interface module (wherein the id is a reference to a module interface definition or specification) or an actual concrete module which MAY implement one or more interface modules. When asking the module loader to load a module by id, the caller can request a specific concrete module, or can request an interface module and leave it up to the system to determine the most appropriate concrete module implementing that interface.

The WebVM module loader allows different specific loaders to be registered to handle the loading of modules according to domain and a default loader used for all cases that are not overridden by loaders for specific domains.

The default loader assumes module ids of the form:

http[s]:///

where:

• is a domain name (owned by the author or publisher of the module);

• is a REST-style slash (a€oe/a€)-separated resource name.

A module also has a version which is a string. The string can be of any form a€” the loader itself only tests for string equality between versions.

Module ids may be combined with parameters when loading modules (particularly if, for example, specifying additional parameters with an interface module request to help the system resolve the request to a concrete module satisfying certain properties). A parameter set is a set of name,value pairs where name and value are strings.

Module loading

The module load API is as follows:

webvm.load(name,version,params)

where:

• name is the module id;

• version is a specific version string or a version specifier22;

• params is an object encoding the parameter set.

The loader first determines whether or not a matching module has already been loaded, according to the following criteria:

• a loaded module with identical name and params, and identical version;

• a loaded module for which:

• the domain part of the name is identical;

• the resource part of the name is identical, or a stem of resource part of the requested name;

• the module includes, in its meta data, a matches function which evaluates to true when called with the requested name, version and params.

If no currently loaded module matches, the default loader resolves the request to a CGI-encoded URI of the form:

name?version=&

The loader attempts to load the module by HTTP GET on this URI.

Support for API security

This section is a placeholder for specific functionality to be decided. It is desirable to provide some support for JavaScript API security so, for example, a web application can use a private API key for a specific web service, and pass that key to a WebVM library, without making that key vulnerable to interception by other scripts running in the same page.