This document: http://www.w3.org/TR/NOTE-expamaya
Author: Daniel Veillard, W3C, <veillard@w3.org>
This document is part of the Amaya activity. A list of current NOTEs can be found at: http://www.w3.org/TR/. This NOTE will not be maintained, so we kindly ask you to refer to the included URLs for the latest information. The mailing-list www-amaya@w3.org is also a good way to get the latest informations on Amaya.
This note is written to explain (for example to members of the DOM and HTTP-NG working groups) the internal structure of the special versions of the Amaya client which are provided as testbeds including Java or ILU.
A related note NOTE-Amaya-970220 presents Amaya, the W3C testbed client.
Amaya is a Web client that acts both as a browser and as an authoring tool. It has been designed with the primary purpose of being a testbed for experimenting and demonstrating new specifications and extensions of Web protocols and standards. Amaya is made of three main software pieces:
The following picture describes this framework:
The Thot API consists of approximately 260 functions allowing one to create, display and modify structured documents. The Amaya API currently includes around 40 functions, mostly related to Amaya user interface and style sheet support, and could probably be extended to provide more flexibility.
Two extension have been made to this existing framework with the purpose of helping building testbed with Amaya.
The first one was to embed a Java interpreter in Amaya (the Kaffe JIT Java virtual machine). The resulting program contains both a standard C environment where most of the actual Amaya application runs, and a Java Virtual Machine. One of the main changes concerning Amaya in this environment is the use of the Jigsaw (the W3C HTTP server and proxy) HTTP code for network accesses instead of libWWW. Using the Jigsaw API it is easy to customize the HTTP behaviour like adding filters to HTTP requests or using an advanced proxy scheme.
A set of stubs gives access to all the interfaces of the Thot and Amaya APIs from the Java environment. This allow code written in Java to modify the documents content or control it's presentation. One of the possible use of these functionalities is to build a DOM (Document Object Model) testbed written in Java and taking full advantage of the structured document model offered by Thot toolkit.
Here is the picture describing the Amaya-Java framework:
Most of the stubs used to make the interface between Java environment and the C runtime are automatically generated from the public C interfaces headers. A small set of Java classes have been built on top of the raw native interface to encapsulate it and provide an object-oriented metaphor for the object types commonly used in the Thot library. This version of Amaya is distributed since June 97 along with the standard one under the name amaya-java. One of the main limitation of Java support in Amaya it the unreliability of AWT support in Kaffe. Kaffe doesn't use the Java AWT classes and relies on the Biss classes emulating AWT, the emulation is nor perfect and the support for the Biss classes has been removed in the latest version (should reappear soon).
Another extension - nearly completed but not yet distributed - is to add ILU (Inter Language Unification) to Amaya. It allows to access remotely to a set of interfaces exported from Amaya through ILU. This allows for example another program running remotely or on the same machine to access the Amaya core functionalities. The interfaces are defined in ILU's Interface Specification Language (ISL) and can be accessed from a large set of languages. ILU also offers various transport layers (RPC's, HTTP, ...) and can be used as a a CORBA ORB system.
The first ILU-Amaya prototype actually uses ILU HTTP implementation to fetch Amaya pages. Currently the support for the loading of inlined object is not ready, but this will hopefully be fixed soon. This picture shows the architecture of this first prototype:
Using the Amaya API exported by this version of ILU, it is extremely simple to build add-on packages able to run remotely and which affect the behaviour of Amaya. For example building a client programs which force Amaya to load a specific URL takes a few lines of C code (mostly initialization stuff). Due to ILU support for a large number of language such client could be either built with Java, Python, C++, Modula, etc ...
Like for the Java integration, the stubs are automatically generated from Amaya C header files, a first stub generator produce the ISL definition and a C module used for ILU front-end. Then the ILU stub generator is invoked on the ISL file to build the server and client modules needed:
Using a stubber for another language on the ISL file alllows to build the glue needed to interface it with Amaya exported interfaces.
This last testbed version includes both the Java runtime and the ILU stubs. The HTTP accesses are done using the Jigsaw client code. It basically offers both the Java ILU interfaces to the core of Amaya:
Since this testbed is using the Jigsaw HTTP interface for fetching pages and inlined objects, it doesn't suffers from the same problems of the pure ILU version. The ILU interfaces also offers the ILU HTTP stack for remote API accesses.
The following documents are available on the web: