UA/Browser NPAPI plugin

NPAPI is the key interface. Especially the scripting extensions. WebVM is similar to LiveConnect or gears.

• whitepaper
• NPAPI on different platforms
• Debugging
• webvm plugin tests which can be found in the private code/tests/html directory in subversion
• Build notes

WebVM in practice

• Providing SIM Authentication
• Demonstrating the plugin
• webkit
• maemo
• China mobile notes

Mozilla Gecko

• API reference
• Liveconnect
• NPAPI overview

Notice that Liveconnect might be removed from gecko and re-implemented using the extended scripting NPAPI interface.

Object element

See api

RE Jblend Scripting Extension (webvm) functional specification. This [old resource at netscape[(http://web.archive.org/web/20040405071231/devedge.netscape.com/viewsource/2002/markup-and-plugins/) has some more information regarding about element choices.

The idea with webvm is that a Java library can become a scriptable entity, in much the same way as an ActiveX control is scriptable within IE. The webvm control (or module) can expose any API it likes to Javascript, and can make use of any of the underlying Java APIs it needs.

So in the Java library you might have a class

class MyCoords {
  double lat,long;
  MyCoords (double x, double y) { lat = x; long = y}
}

and the Java library might expose a method getMyCoords()

MyCoords getMyCoords() {
  Location loc = new Location();
  QualifiedCoordinates coords = loc.getQualifiedCoordinates();
  return new MyCoords( coords.getLatitude(), coords.getLongitude ());
}

This getMyCoords method is the API we want the library to expose to Javascript.

webvm is integrated as a scriptable browser plugin, so it is necessary to instance the library using an tag:

<OBJECT id="webvm" archive = " http://mydomain.com/location.jar">

Then your Javascript is:

var mycoords = document.webvm.getMyCoords();
var lat = mycoords.lat;
var long = mycoords.long;

I realise this description is sketchy but I hope you get the idea.

In practice we think you’d want to wrap the and any other helper code into a Javascript module so you can present any API you want at the Javascript level, so the form of a Javascript API doesn’t make the directly visible to the Javascript programmer. The idea is that we want webvm to be ONE mechanism to make JS APIs deployable - and if there’s a standardised JS API for, say, location, it could either be directly implemented in the browser, or enabled in the browser via webvm. Of course, what webvm also allows you to do is avoid defining any APIs, or defer the standardisation of APIs, because it can support an ecosystem where individual developers can create and deploy their own APIs provided the browser itself has the webvm plugin.

Local Web service Java application

As mentioned in mobileajaxws-pp’s diagram, an idea perhaps is to fallback on some sort of local httpd device service running on JBlend.

There might be a case when we can not deploy the plugin. The Web service is not desirable as it will probably be quite slow.

Configuration

See config for further details.