These are the main differences between this version and JASigning 0.9.5c:
The two LiveConnect applets have been replaced by a single SiGML Player Applet, which accepts either form of SiGML sequence specification recognised by its two predecessors, that is, a SiGML URL or an explicit SiGML text. It provides feedback to the HTML GUI via Javascript calls.
The applet controls its signing avatar panel via its own event dispatch thread (EDT), which responds to two classes of event: GUI events coming from the user via the HTML/Javascript LiveConnect interface, and call-back events generated by the avatar panel itself. The EDT generates an acknowledgement for each event it receives and at present it processes events serially, that is, it will not accept a new event until it has generated the acknowledgement for its predecessor.
The EDT is thus a potential bottleneck, but the JASigning avatar panel component is intended to operate with enough asynchronous concurrency for this not to be a problem in practice.
This event-based architecture should make it a relatively straightforward matter to enhance the applet while maintaining its robustness: a new operation can be introduced by making appropriate exensions to the applet's Event enumeration, and adding code to the EDT specifying how each new event is to be processed.
The applet has a boolean option controlling the generation of event logging output on the Java console.
(The LC-SiGML-Player and LC-SiGML-URL-Player applet classes are still included
in the use-jarp library, but this release does not provide any
HTML demos for them.)
JASigning now allocates a local workspace for itself in a directory
called .jasigning in the user's home directory.
If the user wishes to define a default JA options set, that is, one
common to all JASigning applications, then the file defining these options
(jadefaults.properties) should be placed in the user's
.jasigning directory.
In the absence of this file, a standard JA default options file (which
typically is empty) is read from the JASigning installation server instead.
For an avatar with Cacheable access, the locally cached copy is now
held in the user's JASigning workspace (.jasigning directory)
rather than in the JNLP Persistence Service cache, as before.
This means that avatars with Cacheable access can now be used by JASigning
HTML applets (which do not have access to the JNLP cache).
As a result, Cacheable access is probably now the most satisfactory
avatar access mode in most contexts.
JASigning now supports a standard installation-wide set of avatar configuration options. The properties that may be defined in this set are:
avatar.idavatar.id.listdirect.files.avatar.listcacheable.avatars.listavatar.config.base.uriavatar.jar.base.uritogether possibly with appropriate entries, each for an individual avatar, AV, in one of the forms:
avatar.direct.base.uri.AV (if AV has Direct Files access)avatar.jar.uri.AV (if AV has Cacheable access)(See the previous release's change list for descriptions of these options.)
The built-in JA options set does not now include settings for any of these options, but the standard JA options set may still include definitions for them through the JA default options and/or the application/applet-specific options.
Definitions of avatar options in the JA options set supplement and override the installation's standard avatar configurataion options. Thus, for example, the installation may define a basic set of avatars and standard locations for their definition files, while a particular application may define additions to the installation's standard avatar set, together with locations for these extra avatars, and possibly also non-standard locations for avatars in the installation's original set.
The SiGML Editor/Client application now uses the Preferences mechanism to remember the location of its SiGML folder from one invocation to the next. When first used the application prompts the user to choose the required folder via a standard file dialog.
The behavour of the Frame Number spinner component used in the JASigning applications has been reworked and should now be more robust -- for example, in the case where SiGML animation generation is streamed (i.e. asynchronous).
The SiGML Service Player application now supports streamed animation generation, that is, it should be possible (with the appropriate option setting) for that application to play the animation for earlier signs in a SiGML sequence while animation data is still being generated for later signs in the sequence, or even while waiting for later signs to be delivered from the remote source.
RE 2008-12-13