Actors

Reference Document
Web site <http://www.sics.se/dive/manual/actor.html>

Tomas Axling - <axling@sics.se>
Emmanuel Frécon - <emmanuel@sics.se>
Olof Hagsand - <olof@sics.se>
The Swedish Institute of Computer Science Stockholm, September, 1995

1. Introduction and Motivation

This document presents design and implementation considerations of the actor class, also called process bound entity (PBE). It has also been called "application object".

The motivation for actors stem from the need for applications to be able to present its services and be able to offer an interface to other agents in the environment. Older C-based applications, such as Mdraw (a virtual whiteboard application implemented in Dive), can only communicate with the environment through user interactions. If it is implemented as an actor it can present its capabilities to other agents or users.

A second motivation is for external environments, such as Oz and other DCI users, to post tcl-procedures (which in turn calls Oz or whatever) to their tcl-interpreter. These procedures present the external applications capabilities and can be accessed and invoked by other agents.

A third motivation is that current user interface models in Dive do not fit together well. There are persons, renderers, processes. An actor maps these together into one entity. For example, vishnu (the most commonly used interface) can implement an actor. The "vishnu actor" extends the Dive/Tcl interpreter with Tk with the display and window bound to the vishnu interface. Rendering data is made available to other users. In this way, an actor can be seen as a generalized person.

2. Actor structure

An actor contains a list of associated entities with labels with functions for accessing them and adding them dynamically both from Tcl and C.

An actor is bound to exactly one (Unix) process and cannot be rebound to another. If the process terminates it should ensure to remove its actors and their associated entities.

When actors change worlds their associated objects follow. If an actor creates objects without adding them to its associated objects, these objects will be treated as regular objects.

3. Dive/Tcl and actors

The actor is replicated, but in Dive/Tcl terms, it acts as a proxy: all tcl scripts will be evaluated on the process bound to it by rpc. Other scripts calling dive_send or dive_call to it will be forwarded by rpc.

In a sense every actor (and entity) has exactly one tailored made Dive/Tcl interpreter depending on what procedures and variables are declared in it.

One way to find out what services are offered is to call:

     dive_send $id {
        info procs;
        info commands
     }

for some actor identifier $id.

4. How are persons implemented as actors?

The current Dive "person" entity can be implemented as an actor by having associated entities with labels ``top'', instead of being hardwired. For example, instead of calling p->top, you would call something like find_assoc(p, "top") (p is a person).

The "vishnu person" extends the Dive/Tcl interpreter with Tk with the display and window bound to the vishnu interface. Rendering data is made available to other users.

6. Implementation

The "associated entities" are implemented as a vector of <string, id> pairs in the actual actor class with a process address. The actor extends the entity class by the following fields:

      void *addr;                   /* Address of associated process */
      int assoc_len;                /* How many associated objects */
      struct association *assoc_list; /* Variable length vector */

where "associations" are a list of:

      char *assoc_name;  /* Application specific name */
      objid_t id;        /* Object id of associated object */

The following functional interface to find and manipulate associated objects:

http://www.sics.se/dive/manual/cref.f.html#find_assoc http://www.sics.se/dive/manual/cref.a.html#assoc_put http://www.sics.se/dive/manual/cref.f.html#find_assoc_actor http://www.sics.se/dive/manual/cref.f.html#find_assoc_realobj http://www.sics.se/dive/manual/cref.i.html#iterate_assoc_top

The following example shows how to use the iterator function:

            i = -1;
            while (obj = iterate_entity(actor, &i)){
                ... obj is a top-level associated object ...
            }

For implementation reasons, when an actor changes the world, only those associated entities that are direct sub-objects of the current world will follow. It is assumed that if an associated object is a sub-object, the top object is also an associated object.

Removals can be made of all associated objects.

When actors change worlds, all associated objects change worlds and stay in their relative positions. When a transformation is made through a gateway, all objects are uniformly transformed.

The following functional interface to create, remove and changing worlds for actors:

http://www.sics.se/dive/manual/cref.n.html#new_actor http://www.sics.se/dive/manual/cref.i.html#init_actor http://www.sics.se/dive/manual/cref.d.html#dispose_actor http://www.sics.se/dive/manual/cref.d.html#dispose_actor_objects http://www.sics.se/dive/manual/cref.m.html#migrate_actor

7. Application support

Higher level services can be supplied by an actor module, not a part of the Dive core system. The following sketches out some possibilities for agent-based systems.

7.1 Building a Transducer

A transducer mediates between an application and Dive. The transducer accepts messages from the application and translates them to Tcl and sends the Tcl command through a DCI connection to Dive and vice versa. The DCI connection creates an actor with which the application can present its services to other ``Dive citizens''. This is how the new Oz interface is implemented and is the recommended way to interface ``non-embeddable'' languages or other applications that cannot be compiled as a Dive application. All DCI connections have an actor making them accessible to others. There should be a wait-for-return-value function in the DCI Tcl interpreter: I.e., to be able to send a command on the "backchannel" to the client and wait for an answer.

7.2 Building a Wrapper

A wrapper injects code into an application to make it speak Tcl. This is done in Dive applications by creating a actor with a Dive/Tcl interpreter and to add commands to that interpreter. This is the best alternative when it is possible, such as for old dive applications as MDraw. The actor of MDraw would have ``board'' as associated entity.