Position Paper for the WWW5 Programming the Web Workshop (May 6-10, 1996, Paris, France)

CAMEO: Supporting Observable APIs

Andy Wood
amw@cs.bham.ac.uk
The University of Birmingham
School of Computer Science
Edgbaston, Birmingham B15 2TT
United Kingdom
http://www.cs.bham.ac.uk/~amw/

currently on sabbatical at the
Graphics, Visualization & Usability Center
College of Computing, 801 Atlantic Drive
Georgia Institute of Technology
Atlanta, GA 30332-0280, USA

Scenario

Lein sits down at his computer to write a paper. He taps a few notes into his word processor to help organise his thoughts. In the background, a program notices that he is brain storming and extracts the keywords from the notes as he types them in and submits them to a web search engine. It collects and collates the results onto one page and quietly displays a reference to it at the bottom of the screen, updating the page as he types in further words.

By now Lein is running out of ideas, but he notices these new search results and decides to take a look at it by clicking on the reference. This causes a web browser to be started, showing the page. Realising that he is likely to get "lost in hyperspace" following the search results, Lein starts up his web map application too. This rather nifty little program watches Lein as he follows hypertext links and builds a three-dimensional map of his progress so that he may quickly return to any interesting pages that he finds.

After a couple of clicks, Lein's intelligent cache program spots that page accesses from European domains are taking a long time and so it kicks into action. It works by examining the page that Lein is reading and trying to guess which link he will follow. If that link happens to be in Europe then it caches the page. If Lein does choose the page, it is very quick to load, if he doesn't, then he hasn't lost anything, and the algorithm uses the negative feedback to improve its guesses.

Having found a couple of interesting pages, Lein bookmarks them. This triggers his auto bookmark sorter into action - it quickly chooses a catagory to file the bookmark under and prompts Lein to accept its choice, allowing him to choose a better one if he wants. The bookmark addition is also observed by his news filtering program and keywords from the pages are used to update his user profile.

Lein returns to his paper, newly inspired.

Introduction

Currently, APIs are event black holes: things that happen at the user interface (such as a user clicking on a button) or the programming interface (like a program invoking a remote procedure) are nearly always invisible to third-party pieces of software. Similarly, it is usually impossible for a program to watch changes in the state of another program unless the API explicitly supports such notification.

In the scenario above, user interface actions (such as clicking on the search reference and bookmarking a page) are used to trigger processes (like starting the web browser and the auto bookmark sorter). Events taking place at APIs (such as the loading of web pages) are also used in a similar manner (to start the cache program). Parts of a program's state (like the text in the word processor and the HTML in the browser) are often monitored too.

We will refer to APIs that support these forms of monitoring, notification and triggering as 'observable'. cameo is a C++ toolkit and associated model that allows programmers to easily build observable APIs. This paper will briefly describe cameo and some of our experiences in using it to build hyperspace the "rather nifty" web map application mentioned in the scenario.

Related Work

Systems designed with scripting in mind, such as HP's NewWave environment [Stearns, 89] and the Macintosh AppleEvents engine [Apple, 93], often incorporate observability. This is so that applications can be recorded by generating a series of events that can be saved as a script, ready to be replayed at a later date. Unfortunately, in the case of AppleEvents at least, applications built to support them do not necessarily have to be recordable, they may just accept events.

Message bus systems such as ToolTalk [Julienne and Holtz, 93] and KoalaTalk use a centralised message server that receive messages from applications as events occur, and then routes them to interested third-parties. "Interest" in a message is registered by sending a pattern to the message server - if the message matches the pattern, it is forwarded. The main problem with message buses is that they do provide a centralised service, and consequently do not scale particularly well.

The X consortium's X-Agent project is designed to allow an X application's user interface to be observable. The primary motivation for this work is to allow alternative (such as purely audio) interfaces to be provided for standard X applications. Although supporting observability of events at the user interface is useful, it is only half of the story: in our scenario, many events happened at APIs which do not necessarily have to have an associated widget.

The k-Edit system from the Koala project at INRIA is more generic and simply defines an abstract set of nodes at which events can occur. These nodes could represent parts of the user interface, or parts of an API. In many ways it has a very similar functionality to cameo, but being written in C, rather than C++, means that it works at a slightly lower level.

cameo has much in common with distributed object systems work like OMG's CORBA and Xerox Parc's ILU, although neither support observation explicitly. It is also related to multi-agent language projects like KQML and SodaBot.

CAMEO

The development of the cameo environment has been largely influenced by a technique called status/event analysis [Dix et al, 93; Wood, 96]. Using this technique, systems can be decomposed into parts that have a set of status and events associated with them. Events are transient things that happen at a particular moment in time, while status are persistent values that can always be sampled. Events are passing things like beeps or keypresses, whereas status is reflected in things like mouse or cursor positions. In programming terms, events can be compared to actions like the invocation of a remote procedure, or the calling of an object's method; while status are data values or variables.

This is an obvious distinction between the two sorts of phenomena that occur at interfaces, and yet status and events are inextricably linked: an event often causes a change in status, and a change in status is an event.

In cameo then, an API is described in terms of the events (methods) and status (values) that it has. Once it has been defined, other programs may perform a combination of three primitives on the interface:

Comparing the cameo primitives with the basic k-Edit operations for a second may help clarify these terms a little. Examination may be used to list the interface hierarchy, and to get status values. Manipulation allows status values to be set, and actions/methods to be exec'd. Observation allows a program to be notified of changes in a status value (the gets and sets), and also about the invocation and results of an action/method (the execs). The implementation of observation was implemented using the Observer design pattern [Gamma et al, 95].

cameo also provides a simple directory/location service, so that programs may find each other by name, type or the interfaces they support.

hyperspace is a highly dynamic system that takes a web browser (NCSA Mosaic) and a visualisation program (Hyper/Narcissus) and integrates them to provide the user with a three-dimensional map of the hypertext structure of the pages as they are browsing. When running, the system is made up of four components:

Only mosaictransducer and hyper have cameo interfaces - Mosaic uses CCI, and the observer program just uses cameo primitives, it doesn't have an interface as such. The interfaces can be described like this:


mosaictransducer
Note: in a perfect world, the show event/method would actually be a status value - so that it could be sampled at any time - however the CCI protocol does not allow such an operation, and so show has to be an event. By using a URL cache in the mosaictransducer we could implement it as a status value, but we have not done this as yet.
hyper

The observer program does this:


LOCATE mosaictransducer AND hyper

START OBSERVING mosaictransducer.show AND hyper.openObject

WHILE running

    WHEN OBSERVED mosaictransducer.show ( url )
        MANIPULATE hyper.insertNode ( url )
        get information about hypertext links from page at url
        MANIPULATE hyper.insertNode ( children )
        MANIPULATE hyper.insertLink ( url, children )
        MANIPULATE hyper.setNodeAttr ( url, size, numberOfChildren )

    WHEN OBSERVED hyper.openObject ( url )
        IF url is not currently showing THEN
            MANIPULATE mosaictransducer.show ( url )
        ENDIF

ENDWHILE

STOP OBSERVING mosaictransducer.show AND hyper.openObject

The net result is a system that follows you around the web (by observing the show events) and builds up a map (by manipulating the insert* events) that you can use to navigate (when you open/click on an object in the visualisation window, this interaction is observed and causes the page to be shown).

Using cameo to build the hyperspace encouraged us to decouple the various components that make it up, helping us to create a system that we can plug and play with. We have already improved the observer program many times without needing to change the mosaictransducer or hyper code. Both mosaictransducer and hyper have subsequently been used to build other cameo based systems without changes (a HTML mail reader and a disk controller visualisation).

Future Work

We are currently working on using cameo to integrate a mail reader with several other applications (calendar/database/web browser) to test its capabilities in a different domain.

We also believe that cameo may provide a good basis for many groupware systems, although issues of privacy and security will have to be more fully addressed

Conclusion

Many desirable systems can be easily implemented and extended by if their components have observable interfaces. And even though observability is often used, most interapplication communication systems do not explicitly support it, forcing programmers to adopt ad hoc implementations.

The cameo system is a good prototype of a toolkit that supports observability. It allows programmers to simply create observable interfaces and is based upon the straightforward and well defined concepts of status and events. It has been used successfully in the hyperspace system, and a couple of other small test systems.

Even if being observable is not an essential requirement for web programming APIs, it is at least a highly desirable one.

Acknowledgements

This work owes a lot to Russell Beale, Gregory Abowd and Nick Drew.

References

[Apple, 93] Apple Computer, Inside Macintosh: Interapplication Communication, Addison-Wesley, 1993.

[Dix et al, 93] A Dix, J Finlay, G Abowd, R Beale, Human Computer Interaction<, Prentice Hall, 1993.

[Gamma et al, 95] E Gamma, R Helm, R Johnson and J Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.

[Julienne and Holtz, 93] A Julienne and B Holtz, ToolTalk and Open Protocols: Inter-application Communication, SunSoft Press/Prentice Hall, 1993. (also: ToolTalk FAQ)

[Stearns, 89] G R Stearns, Agents and the HP NewWave Application Program Interface, Hewlett-Packard Journal, v40 n4, pp32-37, August 1989.

[Wood, 96] A M Wood, CAMEO: Implementation Support for Status and Events, Position Paper for CHI 96 Basic Research Symposium, April, 1996.