ToolTalk Concepts

Note: ViewKit currently supports ToolTalk development only on AIX 4.1+, DEC UNIX 4.0+, HP-UX 10.10+, Solaris 2.4+ and SunOS 4.1+. The ToolTalk classes are not provided in the ViewKit library for other platforms. The ToolTalk development library provides low-level functions for setting up connections to the ToolTalk server and sending and receiving messages. The ViewKit message facility is built on the ToolTalk development library to provide a higher-level interface to create and handle interprocess messages.

This section provides a brief review of some ToolTalk concepts and terms. For a complete description of the ToolTalk message service and directions for creating applications that interface with the ToolTalk service, consult the ToolTalk Programmer's Guide.


The ToolTalk message service allows independent applications to communicate with each other without having direct knowledge of each other. Applications exchange ToolTalk messages to communicate with other applications. Sending applications create, fill in, and send a message; the ToolTalk service determines the recipients and delivers the message to the receiving applications. Receiving applications retrieve messages, examine the information in the message, and then either discard the message or perform an operation and reply with the results.


Messages consist of a character string operator, followed by any number of arguments. The arguments can be integers, character strings, or binary strings. Also, a message can have attributes such as a filename. The receiver of a message is told the number and type of arguments, and is also given access to any attribute values.

Registering a message pattern

For each type of message an application wants to receive, it must register a message pattern with the ToolTalk service. The message pattern describes the operator, arguments, and attributes that a message must have to be delivered to the application. When the application registers a pattern, it must indicate whether it wants to observe or handle messages of that type. Any number of applications can observe a message. The ToolTalk service forwards a copy of the message to each application with a matching message pattern. On the other hand, to ensure that a requested operation is performed only once, only one application can handle a message. If the ToolTalk service cannot find a handler for a message, it returns the message to the sending application indicating that delivery failed.

Types of messages

There are two types of messages:

  • Notices
  • Requests

Sending applications

A sending application sends a notice to provide information to other applications; the sending application does not expect a reply to a notice. A sending application sends a request to ask another application to perform an action. The sending application expects a single reply to a request.

Receiving applications

Receiving applications receive notices and perform the actions required to process the notice; the receiving applications do not send reply messages in response to notices. A receiving application receives the request, performs the actions required to process the request, and sends a reply message.

The ToolTalk service handles the details of how requests are handled, and ensures that only one receiver gets to reply. When the ToolTalk service determines that a message needs to be delivered to a specific process, but the process is not currently running, it looks for instructions (provided by the application at installation time) on how to start the application.