The intention behind the introduction of this dynamic association
concept (which after all reduces perfomance) is to prepare WebMap for
code modifications during runtime. Because [incr Tcl] is an
interpreted language, it is possible for WebMap to receive code fragments from
other applications and execute them.
For example, a running WebMap program may receive a class definition implementing a new 3-D-look canvas widget. Then an object of this canvas widget class, which has to be derived from the event receiver base class, may be created. The only thing to do to present the map in a nice 3-D look, is to register the new object with the event dispatcher. From now on, the events for updating graphic windows will be delivered to the old and the new canvas widget objects and the user will see the same map in two different styles.
Tcl (and therefore [incr Tcl]) allows fetching the definition of procedures at runtime and sending or storing them. Through this capability, it is planned to provide a WebMap code server to make world-wide software updates of WebMap programs possible at runtime.
An obvious communication mechanism for WebMap is the Hypertext
Transfer Protocol (with a little help from Mosaic). This means that
special HTML pages (e.g., ``domain entry pages''; see page
) may be enriched with [incr Tcl]-code
as meta-information which is waiting to be executed by WebMap.
In other words, this allows for navigation-support- and other
agents
to be sleeping inside of HTML-pages. Once such a page is loaded by a Mosaic
browser which is connected to a WebMap tool, WebMap
serves as the engine to execute the contained agents.
To prevent such agents from doing any harm, it is planned that WebMap executes them using an extended Safe-Tcl interpreter. (Safe-Tcl is another Tcl extension which was designed to support `intelligent' electronic mail, see [7].)