History of webace

This version of webace is based on the the version distributed from the National Agricultural Library (NAL) of 10th April 1997 http://probe.nalusda.gov:8000/acedocs/webace.html written by JD Barnett jbarnett@gig.usda.gov. This version is complete, i.e. you do not need to download anything from http://probe.nalusda.gov:8000/.

The NAL Webace distribution implemented access to any acedb database via a series of cgi scripts which communicate via an aceclient for text queries and the standalone giface program for graphical images.

One problem with the NAL distribution was the speed when producing graphical views from an acedb database, such as fmap displays. This was due to graphics commands being passed to a standalone giface program, which would have to start, load the database, iterate to the correct state and then output a gif, for each display update. Text queries were much faster since they are routed via Aceclient (via perl and Aceclient.pm) which is a lightweight process. Aceclient communicates with an aceserver which remains up for long periods, so substantially reducing startup time.

An improvement to this was to incorporate the extra NAL giface commands into the core acedb code to create an enhanced aceserver (gifaceserver); the extension of the gif commands to reduce the reliance on multiple mouseclicks and the export of information about the objects represented in each gif as a file. Just as giface writes gif files directly to local disk, gifaceserver does the same, rather than passing the data back data via Aceclient. This technically breaks the client/server model (although the acedb client/server model already uses local file creation to implement its security model), however when creating gif's the gifaceserver/Aceclient relationship should be seen instead as a heavyweight/lightweight application interaction rather than a true client/server one. This is in fact highly appropriate for a stateless web based system, since each action starts a new process.

A second improvement was the migration from serverside to clientside maps. In the original system, when a gif was generated this became a serverside map - a click anywhere on the map results in a new gif (with associated delay before it is created) regardless of whether the click would result in anything new. By using the file created at the same time as the gif by the gifaceserver, which gives coordinates of each object, it was possible to embed client side maps in the web page. The Javascript command onMouseOver was used to cause information about the object to be displayed in the status bar when the mouse is held over it. Transmitting the text for client side maps of large numbers of objects is slow, so Javascript was used again to allow a much more compressed format to use used, which is expanded on the client side. Where a display has very many objects a switch is automatically made from clientside to serverside maps - this means that objects can always be clicked on no matter how many there are.

Not all browsers support Javascript, so a Java applet was written as an alternative to the Javascript client side map system, using a similar compressed format.

The availability of 2 'active' graphics display support systems (Javascript and Java based) led to the need of a configuration system to allow the user to select between them. This was implemented via netscape cookies, which allow the user to set a number of different parameters. The system autoconfigures itself the first time a webace pages is used.

Native acedb displays text objects initially with large lists compressed. This feature was added to webace at the same time as a system to cache text objects and keyset lists in the same way that gif's and associated box files are cached. This considerably improved the speed of repetative access to text objects.

In native acedb displays the first click on an object selects and highlights it and the second click displays its contents. Most aspects of the first operation are provided by the mouseover operation, so the default action of a click on an object in a graphics display is as if it was a double click. The single click functionality is however still provided via a selection popup menu. The existence of this popup menu to change the meaning of a mouseclick led to other functions being added, such as labelling, extraction of DNA etc.

Both FMAP and GMAP displays can display very large amounts of information that can be bewildering to the user at first sight. To allow some control of this 'view' control was introducted - a set of standard views can be defined for both GMAP and FMAP displays under curator control along with a set of semantic zooming or other selection rules.

URL objects were included in acedb in version 4.5. When combined with webace they provide the powerful functionality of crosslinks between acedb databases. Clicking on such a URL object in webace will display the corresponding object in the other database. Clicking on the object in a standalone acedb program such as xace will display the object in netscape.