JASigning 0.9.5c - Summary of Changes

These are the main differences between this version and the most recent incarnation of JASigning 0.9.5b:

• Support for the JNLP Applet Launcher (JAL), which allows an applet in a web browser to be launched without any prior download of supporting native libraries and avatar definitions.
  (And which despite its name appears not to use the JNLP APIs, but just the JNLP XML file format.)
  All the remaining changes are consequences of this one.

• No "JASigning Applet Support" installation on the client system, nor explicit offers to install local avatar definitions, if appropriate, when a JASigning JNLP application is launched. Instead all caching of native libraries on the client depends on the Java Web Start caching mechanisms, or, in the case of an HTML applet, on the JAL's own caching mechanisms (whose activities are recorded on the Java console log, for those who are interested). The treatment of avatar data files is described below.

• Hence this version has no need of the system-wide JA_HOME preferences setting. In previous versions JA_HOME usually identified the installation directory on the client system. In this version JA_HOME is effectively a fixed internal setting, forced to point to the remote JASigning base directory on the server.

• Applet-specific properties may now be set via <param> entries in the HTML <applet> element (or in a JNLP <applet-desc> element), the parameter name in each case being simply the the name of the preference setting it represents.
  One consequence of this is that applet-specific properties files are no longer necessary, although they are still supported, for the time being, anyway.

Another consequence is that the special avatar parameter of previous versions must now for consistency be named avatar.id

• There are now three possible access methods for an avatar's data files:

  • ClassPath Access: the folder of data files for the given avatar is packaged in a JAR file together with a Java access class (details below) whose sole purpose is to provide a resource base against which the avatar files can be accessed by a Java class loader.

    Provided this avatar access JAR is placed on the classpath of a JASigning application or applet the avatar is automatically accessible -- and will benefit from Java's standard client-side caching mechanisms.
    The drawback of this method is that on first use, the user is forced to wait while every JAR of this kind is downloaded into the Java client-side cache before the application or applet can start.

    This is the default access method. (And it is also used to access the COMMON/config.xml file.)

  • Direct Files Access: this is essentially the access method used in previous versions, that is, the avatar data files are obtained via a base URL for the folder containing these files -- but in previous versions that was typically a file: URL on the client, whereas now it will typically be a remote http: URL.

  • Cacheable Access: this is similar to the first access method in that the avatar data files are packaged with an access class in a JAR file. But in this case the JAR is not put on the Java classpath; instead JASigning downloads it only on demand and places it in the client's JNLP cache, from whence a temporary copy is taken and dynamically loaded.

    (Using the JNLP cache for this purpose seems to be a mistake since JNLP is not available to HTML applets, so at present this access method is available only to JNLP applications and applets. But using a custom-built cache instead of the JNLP cache -- as JAL does -- would not be difficult to implement and JASigning may well change to do this in the near future.)

  The access class for a given avatar, marc say, is a miniscule Java class called marc.Access whose compiled class file Access.class is placed in the marc avatar data folder. The Java code for this class is simply:

       package marc; public final class Access{}

• There are a number of new properties/preferences settings to control the avatar access mechanisms, and several of the old setttings take on a more prominent role. As noted above, an HTML applet can now control these settings by means of <param> entries in the relevant HTML <applet> element.

  • avatar.id:   The name of the avatar to be loaded initially.

  • avatar.id.list:   Colon-separated list of avatars available to the application/applet, e.g. anna:marc.
    (Since there is no longer an installation folder in the file system, JASigning is no longer able to determine this list for itself by inspecting its agconfig subfolder.)

  • direct.files.avatar.list:   Colon-separated list of avatars using the Direct Files access method.
    May be omitted (or explicitly null, or explicitly empty) if the list is empty.

  • cacheable.avatar.list:   Colon-separated list of avatars using the Cacheable access method.
    May be omitted (or explicitly null, or explicitly empty) if the list is empty.

  • avatar.config.base.uri:   The default base location for the data folders of avatars in the Direct Files list.

  • direct.files.base.uri.AVATAR:   Assuming AVATAR appears in the Direct Files avatar list, an entry of this form explicitly specifies the URL of its avatar data folder, overriding the default location implicit in the avatar.config.base.uri setting.

  • avatar.jar.uri.AVATAR:   Assuming AVATAR appears in the Cacheable avatar list, an entry of this form specifies the URL of its access JAR file.

  Clearly, the avatar.id.list should include the avatar.id value, and should contain as sublists both the direct.files.avatar.list and cacheable.avatar.list values.

• As well as the various client-side cacheing mechanisms, this version of JASigning currently caches all avatar data in memory for the remainder of the session once loaded. This could amount to a good few Mb if many avatars are used, but probably not enough to be a problem in most environments.

• At present this version of JASigning makes no attempt to set the Java Applet runtime parameters for the user, since the separate installer which used to do this is is no longer used.

RE    2008-07-21