Network-transparent events that are not owned by any well-known server (for example, an X server) and that do not have any predictable set of listeners
Automatic tool invocation
A widely-available distributed object system
Of course, there are some inter-operability problems for which the ToolTalk service may not be the appropriate technology to use. However, when your application needs to solve both sorts of problems (that is, a combination of those inter-operability problems for which the ToolTalk service is designed to solve and those problems for which it is not designed), you can use the ToolTalk service in combination with other technologies.
Use the ToolTalk service when you want plug-and-play capability. The term plug-and-play means that any tool can be replaced by any other tool that follows the same protocol. That is, any tool that follows a given ToolTalk protocol can be placed (plugged) into your computing environment and perform (play) those functions indicated by the protocol. Tools can be mixed and matched, without modification and without having any specific built-in knowledge of each other.
Use the ToolTalk service when your application requires control integration. The term control integration indicates a group of tools working together toward a common end without direct user intervention. The ToolTalk service enables control integration through its easy and flexible facilities for issuing arbitrary requests, either to specific tool instances or to anonymous service providers.
Use the ToolTalk service when your application needs to generate or receive network-transparent events. To be useful, traditional event mechanisms (such as signals and window-system events) require special circumstances; for example, you must know a process or window ID. The ToolTalk service allows events to be expressed naturally: in terms of the file to which the event refers, or the group of processes on the network to which the event is applicable. The ToolTalk service delivers events (called notices) to any interested process anywhere on the network. ToolTalk notices are a flexible and easy way to provide extensibility for your system.
Use the ToolTalk service when your application needs network-transparent automatic invocation. The ToolTalk service lets you describe the messages that, when sent from any location on the network, should cause your tool to be invoked. The ToolTalk auto-start facility is easier to use and less host-specific than the conventional inetd(1) facility.
Use ToolTalk when you need to build your application on a distributed-object system that is available across a wide variety of platforms. ToolTalk's object system can be used by any application on all the popular UNIX platforms, regardless of whether the application
Is single- or multi-threaded
Has a command-line or graphical user interface
Uses its own event loop, or that of a window-system toolkit
The ToolTalk Desktop Services Message Set allows an application to integrate and control other applications without user intervention. This section presents two scenarios ("The Smart Desktop" and "Integrated Toolsets") that show how the Desktop Services Message Set might be implemented.
The scenario in this section is intended to illustrate how the ToolTalk service can be used in an application-level program that interprets user requests; it is not intended to illustrate how the Common Desktop Environment product implements the ToolTalk service to interpret user requests.
A common user requirement for a graphic user interface (GUI) front-end is the ability to have data files be aware (or "know") of their applications. To do this, an application-level program is needed to interpret the user's requests. Examples of application-level programs (known as smart desktops) are the Apple Macintosh finder, Microsoft Windows File Manager, and the Common Desktop Desktop File Manager. The key common requirements for smart desktops are:
Takes a file
Determines its application
Invokes the application
The ToolTalk Service provides additional flexibility by allowing classes of tools to edit a specific data type. The following scenario illustrates how the Desktop Services Message Set might be implemented as a smart desktop transparent to the end-user.
Diane double-clicks on the File Manager icon.
The File Manager opens and displays the files in Diane's current directory.
Diane double-clicks on an icon for a data file.
The File Manager requests that the file represented by the icon be displayed. The File Manager encodes the file type in the display message.
The ToolTalk session manager matches the pattern in the display message to a registered application (in this case, the Icon Editor), and finds an instance of the application running on Diane's desktop.
If the ToolTalk session manager does not find a running instance of the application, it checks the statically-defined process types (ptypes) and starts an application that best matches the pattern in the message. If none of the ptypes matches, the session manager returns failure to the File Manager application.
The Icon Editor accepts the display message, de-iconifies itself, and raises itself to the top of the display.
Diane manually edits the file.
Another significant application for which the Desktop Services Message Set can be implemented is integrated toolsets. These environments can be applied in vertical applications (such as a CASE developer toolset) or in horizontal environments (such as compound documents). Common to both of these applications is the premise that the overall solution is built from specialized applications designed to perform one particular task well. Examples of integrated toolset applications are text editors, drawing packages, video or audio display tools, compiler front-ends, and debuggers. The integrated toolset environment requires applications to interact by calling on each other to handle user requests. For example, to display video, an editor calls a video display program; or to check a block of completed code, an editor calls a compiler.
The following scenario shows how the Desktop Services Message Set might be implemented as an integrated toolset:
Bruce is working on a compound document using his favorite editor.
He decides to change the some of the source code text.
Bruce double-clicks on the source code text.
The Document Editor first determines the text represents source code and then determines which file contains the source code.
The Document Editor sends an edit message request, using the file name as a parameter for the message.
The ToolTalk session manager matches the pattern in the edit message to a registered application (in this case, the Source Code Editor), and finds an instance of the application running on Bruce's desktop.
If the ToolTalk session manager does not find a running instance of the application, it checks the statically-defined ptypes and starts an application that best matches the pattern in the message. If none of the ptypes matches, the session manager returns failure to the Document Editor application.
The Source Code Editor accepts the edit message request.
The Source Code Editor determines that the source code file is under configuration control, and sends a message to check out the file.
The Source Code Control application accepts the message and creates a read-write copy of the requested file. It then passes the name of the file back to the Source Code Editor.
The Source Code Editor opens a window that contains the source file.
Bruce edits the source code text.
Integrating multimedia into an authoring application
Adding multimedia extensions to an existing application
Extending the cut-and-paste facility of X with a media-translation facility
Integrating multimedia functionality into an application allows end-users of the application to embed various media types in their documents.
Typically, an icon that represents the media object is embedded in the document. Upon selection of an embedded object, the ToolTalk service automatically invokes an appropriate external media application and the object is played as illustrated in the following scenario.
Daniel opens a document that contains multimedia objects.
The window shows the document with several icons representing various media types (such as sound, video, and graphics).
Daniel double-clicks on the sound icon.
A sound application (called a player) is launched and the embedded recording is played.
To edit the recording, Daniel clicks once on the icon to select it and uses the third mouse button to display an Edit menu.
An editing application is launched, and Daniel edits the media object.
The ToolTalk Document and Media Exchange Message Set also allows an application to use other multimedia applications to extend its features or capabilities. For example, a Calendar Manager can be extended to use the Audio Tool to play a sound file as a reminder of an appointment, as illustrated in the following scenario:
Shelby opens her Calendar Manager and sets an appointment.
Shelby clicks on an Audio Response button, which causes the Audio Tool to start.
Shelby records her message; for example, "Bring the report."
When Shelby's appointment reminder is executed, the Calendar Manager will start the Audio Tool and play Shelby's recorded reminder.
The ToolTalk Document and Media Exchange Message Set can support an extensible, open-ended translation facility. The following scenario illustrates how an extensible multimedia cut and paste facility could work:
Maria opens two documents that are different media types.
Maria selects a portion of Document A and cuts the portion using the standard X-windowing cut facility.
Maria then pastes the cut portion into Document B.
Document B negotiates the transfer of the cut data with Document A.
If Document B does not understand any of the types offered by Document A, it requests that Document A sends it a tagged media type. Document B uses the tagged media type to broadcast a ToolTalk message requesting a translation of the media type to a media type it understands.
A registered translation utility accepts the request and returns the translated version of the media type to Document B.
The paste of the translated data into Document B is performed.