13.4. Architecture

The main actor in the in the DCOP world is the client. Every program needing to communicate has only to become a DCOP client. A DCOP server (an executable named, surprisingly enough, dcopserver), runs permanently on the desktop and acts as a dispatcher for messages all clients are passing. The dispatching is completely transparent to the clients. Hence, from their strict point of view, clients are peers of each other.

The protocol supports both "send and forget" (like a mail message) and "call then listen" (like a telephone call) functionalities. The DCOP server provides a means for client registration. Only clients that are implementing data processing need to register with the server (that is, clients that will receive and process messages have to make themselves known to the DCOP server). The calling-only clients can use the messaging mechanisms anonymously.

All communications are performed using data serialized by means of the QDataStream technology just described.

Messages can be

• Method Calls—In this case, the name of the object in the receptor client that implements the called method.

• Signal Emissions—This allows Qt-style signal/slot communications over DCOP.

Knowing the receptor client for an issued message isn't mandatory because message broadcasts are allowed. Usually, however, the receptor client is specified.

Figure 13.1 offers a graphical presentation of the DCOP client/server architecture.