User reference manual

The user reference manual describes on a practical mode how to use the protocol by manipulating the various entities constructed by the protocol. This description is provided first abstractly before detailing the graphic user interface.


The CO4 protocol makes use of various notions that must be understood in order to manipulate them. These definitions can also be found in the glossary.


A CO4 repository is defined by its name. It must be declared to an agent name server (ANS). A repository is thus created by declaring:

The content of the repository and all the data necessary for CO4 are stored by the ANS (see Storage in Understanding the CO4 behaviour).


Once the repository has been created, there are various kinds of actions which can be performed. They are presented below.


General primitives () deal with the system issues of starting and stopping a repository. These actions are not part of the CO4 protocol but they are necessary to its everyday work.


Initiatives concern the CO4 actions that can be taken by an individual repository. Once issued, they are stored in the set of initiatives of the repository. All but "evaluate" and "deny" are subject to acceptation by the other subscribers (thus require the use of a CFC).


Each proposal, initiative and CFC has a status which can be (see ):

Only proposals can be directly answered, and the answers will affect the corresponding CFC and initiatives. The possible answers are (see ):

Content management

Since the messages exchanged between the repository and its group repository contain some assertions, it is possible to manipulate them and to add them into its own repository content. Thus when some content is carried by a message, it is possible to apply the following actions to it (see ):

CONTAINED when the assertion is already in the repository;

CONTRADICTORY when the assertion is contrary to the repository;

ADMISSIBLE when the assertion can be added to the repository.


There are several possibilities for modifying the default behaviour of the CO4 protocol. These simple customisations are currently handled by environment variables considered by the system.

Under UNIX, a variable var can be turned on by typing

 	setenv var 1
and turned off by typing
	setenv var 0

These options will be saved, but the existence of the variables will override the saved options. The various options, detailed below, can also be accessed by the HTML interface (see ).


The default behaviour of the CO4 protocol is silent. However, it is possible to have all the messages sent by a repository printed. This is achieved by setting the CO4_TRACE variable to 1. Each message sent is printed under the following format:

B2 --(.... W=00)-register(tcp:// --> B3  [register]
                B3 --(T=00 ....)-notify(accept) --> B2

meaning that the repository B2 sent to repository B3 a query corresponding to the register rule of the CO4 specification and that it received from B3 the notification of its acceptation.

Moreover, a [mbox] printed at the end of a line signifies that the receiver repository is down and that the message has been stored in its mailbox.

Setting CO4_TRACE to 0 will prevent the messages to appear.


When a CFC, a proposal or an initiative has reached a final status, it is discarded from CO4 data structures, to save space. Setting CO4_KEEP_ALL environment variable to 1 will keep them, while setting it to 0 will discard them (by default).


The default behaviour, when issuing a CFC consists in transmitting the initial proposal (containing the identification of the issuer). It is possible to mask this information during the voting process by setting the CO4_ANONYMOUS environment variable to 1. A value of 0 will show this information. This only matters in group repositories.


An individual repository can prefer to automatically accept propositions, or to automatically accept proposals due to itself, instead of voting every time. Just setting CO4_ACCEPT_ALL or CO4_ACCEPT_MINE to 1 will make CO4 work more automatically, while setting them to 0 will give more control to the user.


The CO4 package contains a Web browser interface, that provides two frames, one to display CO4 main menu, the other to display either CO4 messages, or the repository content part. Below the various panels of the graphic user interface are presented. They concern three repositories (whose content is a knowmedge base expressed in the TROEPS system) named B1, B2 and B3. B2 is a group repository to which B1 and B3 will subscribe.

Screendump : Initial CO4 panels. The repository B1 has no group repository. Thus it must first register to a group repository.

Screendump : After that B1 has subscribed. B3 subscribes and then receives information from its new group repository: answer to the initiative (subscription), proposals to answer and tells to integrate in its content.

Screendump : More proposals to answer will appear into B1 interface as long as B3 sends new ones.

Screendump . More and more information is communicated to the repository (B1) included new status of initiatives (ACCEPTED) and new proposals.

Screendump : The content of the repositories can be displayed in the CO4 panel. The content is a knowledge base from the TROEPS system. One can observe the "Submit" button allowing to submit the knowledge to the group knowledge base and the name of the creator of the objects (B1) in the repository B3. Since the content of the repository can be different, ne "prenom" of the displayed object is indeed not the same.

Screendump : Configuration of an individual repository (B1). It is possible to register to a group repository or to set the various values presented above. It is also possible to access all the system primitives ("delete", "shutdown", "turn-to-group", etc.).

Screendump : Management of repositories. It is possible from the HTTP interface of a group repository to access the state of the subscriber repositories.