Using Applets

  Applets should be almost completely transparent to the user of the browser. The user has the habit of seeing in-lined images in HTML documents; applets basically follow the same principles, except that instead of static images, a displayed document will now contain GUI elements such as buttons. Each applet will provide its own visual interface, and should also provide the corresponding documentation if needed. Remember that an applet is nothing but a small application, embedded in your browser.

Security

Security is discussed extensively in chapter 3. All efforts have been taken to ensure that applets can be loaded without fear of consequences. There is however one important step in the security mechanism where the user has to make a decision: before a foreign bytecode is linked into the browser, the user is invited to decide to accept or reject the bytecode. The dialog box will show you the PGP signature of the bytecode, if available. As explained in chapter 3, the security mechanisms based on types are defeated if the bytecode has been tampered with (that is, it is not the intact output on an unmodified compiler).

In short: an unsigned bytecode is not secure.

For a signed bytecode, you accept the bytecode on the basis of the trust you grant to the signature's owner.

For a complete understanding of the security mechanisms, please refer to chapter 3.

Relation to HTML

Applets in HTML documents cannot, unfortunately, rely on elements existing in HTML 2.0 or proposed for HTML 3.0. Currently, MMM uses the EMBED element, hopefully following preliminary work on this topic by the HTML Working Group.

The semantics of EMBED is not restricted to applets: the SRC attribute value refers to an arbitrary document, of some MIME type m. The browser reserves some display space inside the HTML display, and calls the visualizer appropriate to type m on the referred document, with, as parameters, the reserved display space as well as the various arguments given by the PARAM elements.

In the case of applets,

• the MIME type is application/x-camlsl;
• the ``visualizer'' is the Caml bytecode interpreter;
• the (required) Function parameter specifies which function (given by a symbolic name) registered by the bytecode is to be called;
• the other parameters are passed to this function.

Applets as browser extensions

The API (Application Programming Interface) offered to applet developers permits more than simply adding GUI elements inside a displayed HTML document. Currently (0.30alpha1), an applet, or more precisely a foreign bytecode, can do the following:

• add a navigation function. Navigation functions are called when a link (e.g. an anchor in an HTML document) is activated. There are several builtin activation semantics :

  goto

  : displays the document pointed by the link

  gotonew

  : displays the document pointed by the link, in a new navigator window

  save

  : saves the document pointed by the link

  The new navigation function will then be available from the Link Activation menu.
• add an event binding for a navigation function. In complement of the previous action, this allows direct access to a new navigation function.

• add an item in the User menu. Functions invoked by items in this menu have access to the currently displayed document (more precisely, to the url of this document). Thus, they will probably do something related to this document, although there is no way to tell for sure.

• add an embedded viewer. As explained previously, the EMBED element is not restricted to applets, but can be used for any type of document, assuming of course the availability of an appropriate embedded viewer.

• add interpretation for a new HTML element. Although standard (2.0) HTML elements cannot be redefined, this feature can be used to experiment with new elements, or implement vendor specific elements.

• add a decoding handler. A decoding handler is invoked when a document has the Content-Encoding header. Examples (builtin decoders) are gzip or compress.

• add a handler for a given HTTP return code.

Control

MMM lets you see what foreign bytecode files have been loaded by the browser, using the OthersCaml Modules menu. Double clicking on the url referencing a foreign bytecode displays the list of functions registered by this bytecode for use by the EMBED element. Each of these bytecode files can also be flushed by selecting it and clicking on Clear. Note that rejected foreign bytecodes are also referenced in this table, to limit the number of network connections.