Common Desktop Environment: ToolTalk Messaging Overview

What Is the Difference Between an Event and an Operation?

An event is an announcement that something has happened. An event is simply a news bulletin. The sending process has no formal expectations as to whether any other process will hear about the event, or whether an action is taken as a consequence of the event. When a process uses the ToolTalk service to inform interested processes that an event has occurred, it sends a notice. Since the sending process does not expect a reply, an event cannot fail.

An operation is an inquiry or an action. The requesting process makes an inquiry or requests that an operation be performed. The requesting process expects a result to be returned and needs to be informed of the status of the inquiry or action. When a process uses the ToolTalk service to ask another tool to perform an operation, it sends a request. The ToolTalk service delivers the request to interested processes and informs the sending process of the status of the request.

Sending Notices

When your application sends a ToolTalk notice, it will not receive a reply or be informed about whether or not any tool pays attention to the notice. It is important to make the notice an impartial report of the event as it happens.

For example, if your tool sends the Desktop Services message Modified, it may expect any listening tools to react in a given way. However, your tool should not care, and does not need to be informed, about whether any or no other tool reacts to the message; it only wants to report the event:

THE_USER_HAS_MADE_CHANGES_TO_THIS.

Sending Requests

When your application sends a ToolTalk request, it expects one tool to perform the indicated operation, or to answer the inquiry, and return a reply message. For example, if your tool sends the Desktop Services message Get_Modified, it should expect notification that the message was delivered and the action performed. The ToolTalk service guarantees that either a reply will be returned by the receiving process or the sender will be informed of the request's failure.

You can identify requests in three ways:

  1. By identifying the operations requested by your tool that can fail

  2. By identifying the operations your tool can perform for other tools

  3. By identifying the operations your tool will want other tools to perform

A good method to use to identify these operations is to develop a scenario that outlines the order of events and operations that you expect your tool to perform and have performed.