Mechanisms for Invoking Actions from an Application

The action invocation API exported by the Desktop Services library is one mechanism available to your application to cause another application to be invoked or to perform an operation. Other mechanisms include:

• The fork/exec system calls

• ToolTalk messages

Each of these mechanisms has benefits and limitations, so you must evaluate your specific situation to determine which is most appropriate.

The advantages of using the action invocation API include:

• Actions can encapsulate both traditional command-line applications (that is, COMMAND actions) and ToolTalk applications (that is, TT_MSG actions). The application that invokes the action does not need to know whether a command is forked or a message is sent.

• Actions are polymorphic and are integrated with the desktop's data-typing mechanisms. This means that an action, such as Open or Print, may have different behavior depending on the type of argument that is supplied, but the behavior differences are transparent to the application that invokes the action.

• Actions provide a great deal of configurability for the application developer, system integrator, system administrator, and end user. Any one of these people can edit the action database to modify the definition of how an action is to be performed.

• Actions work well in distributed environments. If an application uses fork/exec to directly invoke another application, then both applications must be available and able to run on the same system. By contrast, the action invocation API uses information in the action database to determine on which system a COMMAND action should be invoked.

• Actions enable your application to behave consistently with the behavior of the desktop. This is because the desktop's components interact by using actions when manipulating the user's data files.

The disadvantage of using the action invocation API is that it is only an invocation mechanism that has limited return value capabilities and has no capabilities for a dialog with the invoked action handler. If these features are required, fork/exec/pipes can be used. However, within CDE, ToolTalk is the preferred cross process communications mechanism due to its generalized client/server paradigm.

Returning to invocation, suppose your application manages data files in several different formats (text and graphics) and needs to provide a way for the user to edit and display these files. To implement this feature without using actions, you would probably use one of the following mechanisms:

• Use fork/exec to start the appropriate editor and invent some mechanism (for example, environment variables) for the user to specify the names of the editors. The limitations of this approach include the following:

  • You must write complex code that uses system calls to invoke subprocesses and monitors the resulting signals.

  • The editors must either be available on the same system as your application or the system administrator must provide a complex configuration using facilities such as rsh.

  • System administrators and users must learn and manage your application's unique configuration model.

• Use ToolTalk messages to request that operations, such as Edit and Display, be performed on the data. The limitation of this approach is that ToolTalk-based editors must be available for all of your types of data.

To implement this feature using actions, you only have to invoke the Open action on the buffer or on the data file. The action invocation API will use the action database to determine the appropriate message to send or command to invoke as well as handle all details, such as creating and cleaning up temporary files and catching necessary signals.