1. Introducing the ToolTalk Service
2. An Overview of the ToolTalk Service
4. Setting Up and Maintaining the ToolTalk Processes
5. Maintaining Application Information
6. Maintaining Files and Objects Referenced in ToolTalk Messages
7. Participating in ToolTalk Sessions
13. Managing Information Storage
A. Migrating from the Classing Engine to the ToolTalk Types Database
B. A Simple Demonstration of How the ToolTalk Service Works
C. The ToolTalk Standard Message Sets
The ToolTalk Desktop Services Message Set
Why the ToolTalk Desktop Services Message Set was Developed
Key Benefits of the ToolTalk Desktop Services Message Set
The ToolTalk Document and Media Exchange Message Set
ToolTalk Document and Media Exchange Message Set Development History
Key Benefits of the ToolTalk Document and Media Exchange Message Set
General ToolTalk Development Guidelines and Conventions
Always Make Anonymous Requests
Let Tools Be Started as Needed
Reply When Operation has been Completed
Avoid Statefulness Whenever Possible
Declare One Process Type per Role
In the ToolTalk messages there are terms used with specific ToolTalk definitions. This section defines these terms and conventions used in the ToolTalk message man pages.
Table C-1 Document and Media Exchange Message Set Descriptions
|
Edict—An edict is a notice that looks like a request. If a request returns no data (or if the sender does not care about the returned data), it can sometimes be useful to broadcast that request to a set of tools. Since the message is a notice, no data is returned, no replies are received, and the sender is not told if any tool gets the message.
Handler—The handler is the distinguished recipient procid of a request. This procid is responsible for completing the indicated operation.
Notice—A notice is a message that announces an event. Zero or more tools may receive a given notice. The sender does not know whether any tools receive its notice. A notice cannot be replied to.
Procid—A procid is a principal that can send and receive ToolTalk messages. A procid is an identity, created and handed over by the ToolTalk service on demand (via tt_open), that a process must assume in order to send and receive messages. A single process can use multiple procids; and a single procid can be used by a group of cooperating processes.
Request—A request is a message that asks an operation to be performed. A request has a distinguished recipient, called a handler, who is responsible for completing the indicated operation. A handler may fail, reject, or reply to a request. Any number of handlers may reject a request but ultimately only one handler can fail it or reply to it. If no running handler can be found to accept a request, the ToolTalk service can automatically start a handler. If no willing handler can be found, or if a handler fails the request, then the request is returned to the sender in the `failed' state.