How to use WebVM in your Web application

Simply by using Web technologies:

reference the javascript loader.js (hosted by webvm)
javascript that specifies the API to load
code that does stuff with that API

Lets use a simple example:

<!-- Step 1 -->
<script type="text/javascript" src="http://api.webvm.net/loader.js"></script>

<script>
// Step 2
webvm.load("http://api.webvm.net/location");

// Read the docs on http://wiki.webvm.net/api/location/

webvm.runOnLoad(function() {

    alert("WebVM has loaded");

    x = gpslocation.getX();
    y = gpslocation.getY();

    // Step 3
    alert(x+"\n"+y);
})

</script>

For Java developers

Why not become a module vendor?

What does my Web application now depend on?

WebVM provides device APIs to get access to for example GPS co-ordinates. There should be a standard way of doing this one day and you can tailor your Web application to use this standard interface. We are actively participating in the standards making process to ensure our APIs are compatible with Gears & ?Opera APIs for example.

Device API interfaces should be ideally implemented in the browsers themselves in the far future. However in the interim a script to detect whether or not the browser has this feature and if not, use WebVM if detected to implement the interface. WebVM is actually a similar approach to Google gears.

Ok, so lets move the Web forward and here are the end user requirements.

Making sure your device API dependent Web application works across platforms

Scenario: You’re a Web developer and you need a file API and a location API for your Web application.

You don’t know how your customer’s UA will implement this. It might have no support or support from the API frameworks such as:

Or perhaps even a combination of those. Sidenote: WRT location Gears will have interfaces to GPS/WIFI/Cell location tracking and probably give the Web develop the choice between these different type of location APIs.

Assuming compatibility and interchangeability

Application developer adds in a generic/standard device API Javascript loader. Our loader.js is inspired from Google AJAX API.

<script type="text/javascript" src="http://api.openajax.org/loader.js"></script>

This generic/standard loader could be hosted on the Web developer’s domain or in a widget package.

<script type="text/javascript" src="http://example.com/loader.js"></script>

APIs are addressed by URIs and intended to be extensible.

The Web developer now tells the loader which APIs to load.

openajax.load("http://api.openajax.org/file");
openajax.load("http://api.openajax.org/location");

openajax.load should be able to detect if http://api.openajax.org/file is in the widget somewhere.

http://api.openajax.org/file is where the best supporting API is chosen for that device UA. This could be described in JS at http://api.openajax.org/file with the help of DOM objects like window.navigator.userAgent and navigator.plugins. For example:

x61:~% wget -q http://api.openajax.org/file -O /dev/stdout

var ua = window.navigator.userAgent.toLowerCase();

if (ua.indexOf('opera') != -1)
{
    // Not sure how Opera APIs work really
    return "<api type=\"file\" optional=\"optional\">";
}

if (navigator.plugins["WebVM"]) {

// DOC: http://wiki.webvm.net/api/file/

// The webvm.load functionality could be placed in the openajax.load

// This would save the next few lines of code ...
uri = "http://api.webvm.net/loader.js";
var headID = document.getElementsByTagName("head")[0];
var newScript = document.createElement('script');
newScript.type = 'text/javascript';
newScript.src = uri;
headID.appendChild(newScript);

// Provision the WebVM File API
webvm.load("http://api.webvm.net/file");
}

if (window.google || google.gears) {
// Load Google's File API ...
}

The resource at http://api.webvm.net/file will then decide which type of file API to install, ‘Java’ or ‘Native’. This is a WebVM implementation detail, as APIs can either be implemented in Java or C.

So there are potentially quite a few steps to this dynamic API provisioning. Especially if the loader scripts aren’t consolidated into some sort of “standard” location such as http://api.openajax.org/file or http://api.w3c.org/file.

Notes: OpenAjax refers to this as a shim and Android as a “compatibility test script that anyone can run on an Android device to determine which APIs are present and functional”

Loader project - driven by Jon @ OpenAjax

Collection of plugin loaders

Google.load

Google JSAPI
ajax

google.load(“maps”, “2”, {“language” : “ja_JP”});

google.load(“jquery”, “1”);

Note the versioning of “2” for stable, “2.x” for experimental.

Dynamic loading where you can load an API as you need it via a callback is also interesting.

API vending is done sometimes with a key like so: http://www.google.com/jsapi?key=ABCDEFG

Big issues with Google are:

They obfuscate the loader. You load the libraries from them, not a URI like webvm.load does. That has advantages as they have an excellent content delivery platform and they could perform some sort of quality control.

The downside is centralisation. As a third party, how do you get your library hosted by Google? Google could become the Itunes of APIs, a monopoly. Ideally a more politically “neutral” insitution like OpenAjax or W3C should ideally be hosting these API loaders.