Alan Dix
| At time of publication: | HCI Group and Dept. of Computer Science, University of York |
| Currently: | School of Computing, Staffordshire University
alan@hcibook.com http://www.hiraeth.com/alan/ |
Full reference:
A. Dix (1993).
An agent based architecture for groupware applications.
unpublished report, Computer Science Department, University of York.
http://www.comp.lancs.ac.uk/computing/users/dixa/papers/agent93/
See also:
http://www.comp.lancs.ac.uk/computing/users/dixa/topics/status/
and
http://www.comp.lancs.ac.uk/computing/users/dixa/topics/webarch/
Abstract
Implementing groupware can be a difficult and error prone activity, involving both windowing packages and low-level communications protocols. This paper describes how experience implementing an electronic conferencing system lead to the development of an agent based architectural framework for groupware. The agents communicate by both asynchronous message passing and triggered events, the latter being a generalisation of notification based programming. This framework has been implemented in the form of an agent based infrastructure and its use in two applications is described. It was found to be flexible allowing both easy porting of existing applications and prototyping of new ones.
Implementing single-user interfaces is a complicated and time consuming business: the programmer must deal with graphics and window management primitives, the human--computer dialogue and the functionality of the application itself. Groupware adds the problem of distributed computing, programming applications which run distributed over several workstations. Choosing an appropriate computational architecture is crucial - if the architecture is wrong then achieving the desired functionality may be difficult or impossible. Furthermore, a poor fit of application to architecture means that the resulting programs are convoluted, thus discouraging prototyping and iterative design which is widely seen as essential for effective interface design.
Looking at single-user interface design, we can identify two levels at which one can consider such architectures: high-level structural architectures, typified by the Seeheim model for UIMS (Pfaff 1985), and low-level programming architectures, typified by the use of object-oriented programming. This paper attempts to address the latter in the context of groupware: a low-level, programming architecture tailored for distributed interactive systems. The agent-based architecture discussed here has similarities to both distributed object-oriented systems and the actors system (Agha 1986). However, in addition to message passing it also includes an event triggering mechanism which is invaluable for producing multiple views for shared objects and for interfacing with window-managers.
This paper begins by describing experience at York in the implementation of a synchronous electronic conferencing system. The problems and issues raised by this exercise drove the design of the agent-based architecture. Then, in Section 3 the scope is widened to look at groupware implementation issues in general and similar work. The next section describes the current agent-based architecture, first giving the general conceptual framework and then some of the implementation details. Section 5 describes some experience in using the architecture. It describes two systems implemented using the architecture, one a port and the other a fresh implementation. The latter at first interacted badly with the automatic garbage collection algorithms used to implement the agent architecture. It is well known that garbage collection can interact badly with interactive systems, however, additional problems arise when these systems are distributed. Finally, Section 6 describes intended future directions for this work.
Much of the discussion will be about the low-level nitty-gritty of programming groupware. However, effective groupware depends on a combination of high-level analysis of the participants' requirements and correct and efficient low-level implementation. In particular, the latter, the low-level, must be able to easily and flexibly support those requirements elicited by the former.
Between 1989 and 1991 a a series of electronic conferencing systems for synchronous group working were designed and built at York to investigate a range of issues concerning group interaction. These systems came to be known generically as 'Conferencer' and are described in detail elsewhere (McCarthy and Miles 1990; McCarthy, Miles et al. 1991). Figure 1 shows a screen shot of one of these systems. The version shown has two main areas, a conversation area on the left for synchronous textual communication, and a simulated pin-board on the right, where participants can create and edit 'post-cards' which are 'pinned' to the board. This section will describe some of the issues raised by the implementation of these systems.
Figure 1. Conferencer screenshot: showing text transcript and pin-board
Conferencer was designed using a client-server architecture (note 1). A single server process ran on a central computer, which supported all the shared data-structures including the registration of new participants. Several (usually two or three) workstations ran client process. These supported the individual user interfaces, but sometimes held local copies of shared data for performance. Early versions of Conferencer used the 'Presenter' display manager (Took 1990), but later versions ran under the X window system using the XView toolkit (Heller 1990).
Both client and server processes need to be multi-threaded. The client must respond to the user's actions at the interface, but also monitor communication with the server, which may send updates due to other users' actions. Similarly, the server must monitor multiple clients. However, the basic computational model given by C (the implementation language) is sequential and so the multi-threadedness was obtained by stimulus-response programming idioms using mechanisms familiar to anyone who has implemented groupware systems. The client process was driven by the native window manager's event stream, which also supplied events corresponding to client-server communications. The server was written using the UNIX 'select' system call, which enabled the server to wait for a communication from any client and then perform the appropriate action.
In both the server and the client, the support for multi-threadedness is minimal and the programmer must usually save state and mode information in global variables and structures. For example, if the window manager reports a mouse click in a particular region, the program must look-up the meaning of the region (say it is the 'pin' part of a card on the pinboard). It must then look in various data-structures to decide what action should be taken (depending on context, a click on the 'pin' region can re-fix the card after movement or confirm an edit). This is made somewhat less painful when the events are generated using a notification mechanism as is the case with XView. Under this paradigm, the programmer can nominate, for any event type, a 'callback' function which the event manager calls when that event occurs. Some additional information (usually a single integer) can also be stored against the event, this is passed as an additional parameter to the user's function and can then be used as an array index or pointer to a data structure. Furthermore, by changing the callback function and stored data, much of the mode information (such as the state of the pin region) can be stored implicitly by the event manager. Contrast this with a single event stream (as is supplied by Presenter, and as effectively one gets with 'select'). The programmer must produce a single huge 'if-then-else' or 'case' statement effectively decoding the event. The advantage of the notification based event manager is that it handles most of this decoding for the programmer. The trigger mechanism in the agent architecture is inspired by the XView notifier.
For the communications between client and server, the Conferencer used Internet streams via UNIX 'socket' connections. However, this is only a byte stream protocol and the programmer must impose any additional message structure. In particular, the basic protocol does not even distinguish where one message ends and the next begins. For ease of initial programming and debugging, fixed-size ASCII-coded messages were used. The fixed size eased the finding of message boundaries and the ASCII coding made it easy to read the messages during debugging. The intention was that when other aspects of the system were running, these messages would be coded more efficiently - however, by the time we got to such a stage, we had lost track of where the code was dependent on the message structure, and so this 'temporary' message structure persisted throughout the 3 years of the project.
message type :: message body
The exact form of the body depended on the particular message type. Upon receipt of a message, a large 'case' statement dispatched the message to an appropriate handler for the message type. This is very similar to the problems of interface event streams, and suggests that a notification based mechanism is required at the level of process-process as well as human-computer events.
We have reviewed a few of the 'grubby' details of Conferencer's implementation, and one cannot overemphasise the grubbiness and low-level detail that is necessary when programming such systems. In particular, the communications protocols and UNIX 'select' system call are often poorly documented and full of obscure data-structures and options (note 2). Clearly an approach is required which shields the groupware programmer from some of these details, whilst still providing sufficient control and information.
Having looked at Conferencer in particular, we now examine more widely the problems of groupware implementation and existing solutions.
The problems we encountered with Conferencer were neither unique to the system nor to the implementation platform. In particular, the problem of coding a multi-threaded system persists through all common groupware architectures. The architecture used by Conferencer was client-server where both the client and server performed significant amounts of work. There are two extreme positions either side of this.
On the one hand is the architecture used in some X based systems. In these, the server (which is the X client!) performs all the significant computation and the clients (X servers) merely display windows and generate events. The central server receives all X events from each user and responds to them. The server is, of course, highly multi-threaded, as each interface is inherently so and it must handle several. The advantage of such an architecture is that there is only one program and thus there is no need to transfer shared-data between the processes. The disadvantage is that it may be difficult to guarantee sufficient interactive response to each user.
On the other extreme are replicated architectures where the server acts simply as a switchboard or where there is no server and the users' workstations communicate directly with one another. There is no problem with interactive response as the interface code is in the workstation, but now all shared data must be replicated. The replication of data requires locking to avoid inconsistent updates (which again leads to delays in interactive response), or alternatively complex algorithms to deal with such inconsistency if it occurs (for example, Ellis and Gibbs' elegant algorithms for Grove (Ellis and Gibbs 1989)). As in the client-server case, each workstation must both handle both user interaction and communication and is thus also multi-threaded.
In both these architectures the multi-threadedness is obtained using the relevant window event manager. In the centralised X architecture there is one event loop, and no need for communications (these are effectively handled by X), in the replicated case, the event loop must also monitor inter-process communication from other peers. If a notification based event manager is used, this can help, as we found for Conferencer, but this is not the norm, for example, Xlib's 'XNextEvent' call leads to a single event loop with all the problems we have already discussed.
A further problem with the single event stream is its impact on modularity. If we look at a single user-level object, say a text region, we will see code for that object scattered all over the program. In the event loop, we will find a bit of code for handling mouse clicks (to set the selection) some for handling keystrokes, some for specific menus. In addition, if the text is shared there will be code to receive updates from other users in the communications part of the program. So, if one considers a portion of our Conferencer system, such as the text transcript. The reuse of this between different versions of the Conferencer, required not just the inclusion of the appropriate program module, but trawling through the various event handlers to copy the relevant code. At the very best, the main event loop becomes a series of calls to various interface components 'offering' them the event, until one claims it, at worse the code is unreadable and unmaintainable.
In theory, such software engineering concerns need not effect the design of the groupware, but the experience of single-user interface design is that the existence of libraries of user interface widgets makes rapid prototyping reasonable and hence radically improves the design process. If we are to eventually have such libraries of groupware components, modularity at the program level is essential.
There are two classes of low-level architecture which already handle both the multi-threadedness and modularity issues. First, we have the distributed object-oriented systems, such as distributed versions of Smalltalk. These make the physical location of objects largely invisible by replicating objects or by using proxy objects which forward message invocation over the network. Modularity is achieved by encapsulation within objects in the same way (and to the same extent) as in normal object-based systems. Multi-threadedness is more interesting. The normal message invocation is synchronous, that is the object sending the message must wait for the reply. This means that you cannot have, say, a user interface object receive a keystroke and then tell the shared text that it is there - the network delays would mean that the user interface would pause until the message send-reply was complete. Multi-threadedness is instead achieved within each host, by using facilities for different threads of execution under the normal object system. These threads will of course communicate with one another, but will do so by asynchronous means, such as through shared objects with semaphores.
The Actors system is far more radical (Agha 1986). It is similar to object-oriented programming in that each actor encapsulates both data and code. However, being designed for highly distributed, parallel execution, the actors communicate by asynchronous message passing. That is, when a message is sent the sending agent can continue to execute and respond to other messages. If a reply is required it is sent as a separate message from the recipient of the first message to its sender. The multi-threadedness is implicit in the multiple message streams, one for each object, but each agent can only be executing one message at a time. Thus the actors system has effective multi-threading without the problems associated with reentrant code.
Communication in groupware system can be classed into two broad classes, by messages (such as email) or by shared data (as in a shared editor) (Dix 1991). One can imagine the former being implemented by object (or actor) level messages (note 3), but the latter cause far more problems.
A common paradigm in groupware is to have a central shared data item with each user having a view of this item. Depending on the system, these views may be the same or differ (for example, if users are viewing different parts of the document). Imagine the views (which communicate with the window manager) and the shared data being implemented as objects (or actors). When a user performs an update, the view object sends a message to the shared data object which then updates its state.
But how do the other view objects become aware of this change? There are two options, the viewers can periodically poll the shared data, checking to see if it has changed, or the shared data object can send a message to the viewers. These two options, polling and explicit status change events are the normal ways in which an active entity becomes aware of the change in a status (Dix, Finlay et al. 1993; Dix 1992). The former course becomes hopelessly inadequate once there are a large number of shared data objects. The latter requires a fair amount of bookwork on the part of the shared data object. It must be informed by the viewers which of them are interested in it. It must then keep a list of these and then send messages to all objects in this list when a change occurs. This job is so stereotyped that one would like it to be handled by a support system, rather than by the programmer. This will be one of the major tasks of the agent architecture.
The handling of shared data is so fundamental that several systems have been designed which handle specific classes of shared data. DistEdit is one example which supports shared text editing (Knister and Prakash 1990). It does not supply specific views as the intention is that standard text editors will be used. Instead, it supplies the shared text object itself together with a programmer's interface in order to integrate it with standard editors. As an example of a groupware 'widget' (gwidget?) it is excellent, but is of course just one such gwidget and does not supply any more generic feature.
Bentley et al. describe a more generic architecture used for the rapid prototyping of command and control systems (air-traffic control in particular) (Bentley, Rodden et al. 1992). This is based completely around the concept of shared information with 'user display agents' managing views of this shared data. There is an 'update handler' which informs the relevant user display agent when a shared data item is changed. Their system can thought of as the groupware equivalent of a user interface development system as it supplies tools for specifying the structure of shared data items, and for configuring the views. The data model they support is of frame-like entities with attribute-value slots, but they do not handle more complex data structures such as shared text.
We have seen some of the problems in implementing groupware and some existing architectures. The Actors system was well suited to the multi-threaded nature of group interaction and has a message passing mechanism appropriate for distributed processing, but handles shared data clumsily. Bentley et al.'s architecture for a shared information space is successful, but has a quite high-level data model. Our goal then is to produce a low-level architecture which can support shared data in addition to multi-threadedness and modularity. In addition to these goals, we would like to hide the programmer from some of the low level communication protocols and allow some form of location independent code so that the programmer can move functionality between processes without major re-coding.
The architecture chosen is based around agents, each of which (like objects and actors) encapsulates some data and code in the form of methods. There are two methods of communication between agents:
Message passing is asynchronous as in the Actors system. So, if we have two agents A and B, and A has a reference to B, then A can send a message to B. If the message requires a reply, B can send a message back to A as a reference to A is in the original message's 'sender' field. Like actors or objects, the recipient of a message executes the appropriate method, which may cause it to change its state and/or send further messages.
Event triggering is a generalisation of notification based programming. Assume again that agent A knows about B, for example, A might be a viewing agent and B a shared data agent. A can register an 'interest' in a particular event of B, say the 'new value' event, when doing so A says which method should be invoked when the event occurs. During the execution of some method of its own, B can 'trigger' the event 'new value'. When this happens A is informed, in the sense that the method it registered is invoked. We can think of the method that A registers as being similar to the call-back function when using notification. However, the event triggering can be used by any agent, not just in response to primitive user events. One way to view event triggering is that agent A is watching B, and often we may find that the agent triggering the event is otherwise passive: it replies to requests about its internal state, it responds to updates and then broadcasts using a triggered event when the update has occurred. This paradigm where the triggering agent is essentially passive data is not demanded by the agent architecture, but is one of the main techniques which it seeks to support.
Messages and triggered events are very similar except in the way they are generated. Both have a type and some additional data. In particular, the data transmitted with the message or event may include references to other agents. Both are asynchronous in that the generating agent does not stop execution. Furthermore, there is no guarantee that the message or event will be serviced immediately. This clearly cannot be guaranteed across networks and so all that is guaranteed is that if A sends two messages to B they will arrive in the correct order. This is slightly stronger than the message passing in Actors, which only guarantees delivery, not ordering.
The agents are conceived as running on several 'hosts'. In a real system these hosts would be different computers, but for test purposes they may merely be different processes running on the same workstation. Typically many agents will run on each host, but there could be only one agent (indeed there could even be only one host for a single-user interface). There must obviously be a way for agents running on one host to become known to those on another. At present agents can register a name which is then made available on all hosts. Other agents can then ask for a particular agent by name. I am not completely satisfied with this naming, but it has proved satisfactory to date.
The general conceptual architecture could be implemented in a variety of ways. I have deliberately not produced a distributed programming language as the purpose of implementation is to investigate the conceptual issues. Instead, I have implemented a C library together with programming conventions. This allows one to adopt the agent based programming style but still access all the normal C functions, including window manager calls. Some additional syntactic support would be useful, but has not been a priority.
In the current implementation, each host is a UNIX process. Hosts can be launched on different machines, but may also be separate processes on the same machine. Indeed, as mentioned previously, running several hosts on the same workstation can be useful for debugging purposes. One host is nominated as the server and acts as the switchboard between other hosts. This host may, but need not, have agents attached to it. It may act as the centralised application, or may even run one user's interface. The other hosts are clients and similarly may have agents connected with the interface, with the application functionality or with both. The client-server distinction here is purely for establishing network connections, the agents are unaware what role their host has taken and the only impact it may have is on network traffic.
Furthermore, the agents are completely shielded from the underlying communications mechanisms. Currently there is only one such mechanism and the hosts communicate using UNIX sockets on Internet, but it is hoped to extend this to other protocols. When this is done, the same application would be able to run over the new communications protocols. When agents send messages within a host, the message's data is passed virtually uninterpreted, but when it passes between hosts, the infrastructure manages the coding of the messages into the Internet byte stream. The agents only need to supply some type information, but need not know whether the message is local or remote. Figure 2 shows example code for message send and receive.
/* in a method of agent A */
m_info = gen_info("ia",5,an_agent);
send_message(B,"add",m_info);
. . . .
/* in B's method for the 'add' message */
/* B is not necessarily on the same host as A */
scan_info(mess_info,"i",&an_int,&another_agent);
Figure 2. Send and receive a message
The architecture has been implemented over three low-level software platforms. The first uses the UNIX 'select' call and allows textual messages to and from the user's console. The others run under SunView and XView respectively. It is platform independent in two senses: firstly, an agent that does not make explicit use of SunView or XView services runs identically on all three platform, and secondly, hosts running on different platforms may run in the same system. Typically, but not necessarily, the server host would use the 'select' platform and clients could use a mixture of any of the other three. Clients need not run under a window manager as the main application code may well run under a separate client.
We shall look at two examples where the agent architecture has been used to code cooperative interfaces demonstrating its use both for a few large agents and many small ones. One particular problem noted was the interaction between the garbage collector and the interactive response of the system. This is a well known problem for single-user interactive systems, but has a new twist for synchronous groupware.
The agent architecture was being developed at the end of 1991, towards the end of the 'Conferencer' project. After trying several small examples, we made a crude port of the Conferencer system into the agent architecture. This involved defining just one agent for each host, effectively enclosing the existing code. These agents communicated with just one type of message, the body of which was a string containing the original Conferencer ASCII messages as described in Section 2. Thus the sole job that the agent architecture performed was to hide the underlying communication protocol. This crude port took only a few hours one afternoon and thus demonstrated the ease with which an existing system can be brought into the framework.
Another example application was a simulated group shower. This is a simple simulation, where each participant can control hot and cold water taps for their own shower. Obtaining a desired flow rate and temperature is made difficult by two things, the lag as water comes up the shower pipe, and the fact that other participants use of hot or cold water changes the pressure in the system and thus effects your own flow and temperature. The second effect is more often encountered due to the flushing of a toilet and the corresponding scalding water in the shower as the cold water floods into the cistern. However, toilets were not included in the simulation. Like real showers, the simulated showers were nearly impossible to control even without other users.
The simulation was coded using generic 'spreadsheet' like agents. There were three main types: equation agents maintained a value computed from values of other agents, rather like the constraints found in the Garnet toolkit (Myers, Guise et al. 1990), lag agents which produced a value delayed by a certain time, and integrators which summed a value through time. The latter two required large numbers of timer events, and the corresponding high message rates and network loads were an extreme test of the agent infrastructure.
These spreadsheet agents were 'plumbed' to one another and to slider agents at the interface to produce the application. A portion of the code to do this is shown in Figure 3. There is clearly quite a bit of syntactic garbage, but the basic coding of the model is very simple. In fact, the coding of this simulation took less than a day, most of which was spent in producing the generic modelling agents and only a short time doing the plumbing. Rapid prototyping of different models and interfaces is thus very easy and quick.
/* First link to named agents on each user's controls. */ cold_tap1 = find_agent( "cold_tap2" ); cold_tap2 = find_agent( "cold_tap2" ); /* Model for interference, the cold water pressure is */ /* represented by the term (100-(cold_tap1+cold_tap2)). */ cold_flow1 = new_eqn( "$1*(100-($1+$2))/25", cold_tap1, cold_tap2 ); /* Model for first user's flow and temperature. */ /* Delay of 15 seconds as water moves through the shower pipe. */ total_flow1 = new_eqn( "$1+$2", hot_flow1 cold_flow1 ); in_temp1 = new_eqn( "100*$1/$2", hot_flow1, total_flow1 ); out_temp1 = new_delay( in_temp1,15 );
Figure 3. Part of code for shower model
These examples show how flexible the agent infrastructure is. At one extreme, the Conferencer shows how easy it is to gracefully move over to the agent paradigm. Contrast this with a special purpose language or tools demanding a complete re-write of existing applications. On the other hand, the shower example, shows how quickly a completely new application, involving many agents, can be prototyped.
Further, the shower example was used to test out the ease with which an agent based system could be reconfigured. The first implementation had all the mathematical model in the server and the clients had only the interface control agents. This is similar to the typical X architecture or that of Bentley et al. (1992). Different configurations were also tried to vary network load and interactive response. One of these placed all of the model agents in a separate 'application' client, another placed as much of the model as possible in the interface-clients, only retaining the inevitably shared bits in the application client. These reconfigurations typically took less than an hour, requiring the moving of agent definitions and occasionally naming agents to allow cross-host linking.
The agent architecture was built using an existing C package which supplied a range of data types (lists, sets, binary relations). This made it easy to build the infra-structure quickly and cleanly. An important feature of these data-types is that they are subject to automatic garbage collection. This total package gives some of the advantages of running under a prototyping environment like Smalltalk, but still allowed the free use of the C language. No attempt was made, however, to garbage collect agents. Agents are all explicitly created and destroyed. There is thus no attempt to garbage collect between hosts, the garbage collectors only operating within each individual host. True distributed garbage collection is possible and has been studied extensively, for example, in the context of the Actors system (Agha 1986), but the problems cited here do not take into account this extra complexity.
There are well known problems with single-user interfaces, due to the pauses when the system performs a garbage collection. Incremental techniques are possible, but are particularly difficult over a conventional language like C. This had not previously been a problem as the delays for single-user applications (less than a second) had been no longer than the frequent swopping delays on the workstation.
However, with multi-user applications, the delays suddenly became unacceptably long, the machine frequently 'freezing' for many seconds. The reason for this turned out to be implicit assumptions that other hosts would always be ready to receive communications. The result was that the whole system halted whenever any individual host garbage collected. This demonstrates the danger of blocking I/O operations and the difficulty of predicting interactions between distributed components. The problems were solved for the agent infrastructure, but the experience if anything emphasises the need for a well engineered infrastructure which protects the groupware programmer from these problems.
Experience to date has shown that the agent architecture can be used to quickly and flexibly implement new multi-user applications and port existing ones. This ease is despite the relatively crude implementation of the existing infrastructure. The lack of syntactic support has already been mentioned and despite my reluctance to produce yet-another-programming-language, some sugaring, perhaps for inter-agent plumbing, would make it more widely usable. However, there are some more fundamental directions in which work is required.
The conceptual framework does not distinguish a single routing server, and it should be possible to run several servers at widely dispersed sites. In particular, I am interested in the problems of mobile and tele-workers. Hence the architecture should be able to support hosts which are only infrequently connected, or with low bandwidth connections. At present, inter-host communication is based solely on Internet, additional communication protocols should be supported, including RS232, email messages and floppy disk based communications.
Although agents can save state in standard files, there is no generic support for agents to persist longer than the program in which they run. Most synchronous groupware systems (commercial as well as research) have a similar lack of persistence. For example, one commercial application has a text transcript for inter-personal communication while the users edit a shared document. However, when the document is saved, there is no corresponding save of the communication, hence, when they re-start the application, all the rationale captured by their conversation is lost. Supporting persistence at the infra-structure level will make such failures less likely.
Asynchronous messages were chosen because of their naturalness for distributed systems. However, one soon realises how much one uses the implicit synchronisation from a conventional procedure call or object message invocation. One solution is to have a special 'request-reply' message form, with normal object-message semantics. However, explicitly supporting such a facility does question the generality of this standard synchronisation mechanism.
Function call-return or object message invocation can be likened to the idea of an adjacency pair in human-human conversation. But real conversation is more than adjacency pairs. One possibility is to have agent 'conversations' where agents agree to perform certain actions in a certain order (with choice points). These conversations could involve more than two agents and allow more sophisticated synchronised action.
We have seen that synchronous groupware applications require multi-threaded programs and that shared data is frequently a central part of cooperation. The agent architecture suggested here allows the former by using asynchronous message sending and the latter by the use of triggered events. This triggering allows one agent to 'watch' another to see when it changes its state. In addition, these mechanisms make it easier to produce modular groupware widgets (gwidgets).
Experience of using the architecture has shown that it is easy to port existing applications into the framework, making them less dependent on the underlying communications protocols in the process. Also new applications can be rapidly built allowing iterative development which is essential for effective interface design.
Various problems have been identified. The level of dependency between different hosts was found to cause problems with local garbage collectors, highlighting the ease with which unsafe assumptions can be made and the importance of encapsulating the low-level communications. Other directions for future work have been identified, in particular concerning use between highly distributed hosts including portable computers, and the adoption of metaphors from human-human communication to that between agents.
Alan Dix is funded by a SERC Advanced Fellowship B/89/ITA/220. The Conferencer system was implemented by Vicky Miles.