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
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.
Printable version
