Integration Technologies

Common Desktop Environment technologies discussed thus far have been directly involved with putting a GUI onto the screen. The integration technologies described in this section are underlying infrastructure, not GUI providers.

Process Execution

To provide a network-leveraging environment, the Common Desktop Environment provides the Sub Process Control (SPC) mechanism to start, manage, and collect results from applications running on a remote host. A remote host installs an SPC daemon that serves as the remote end of a socket-based control mechanism. This control mechanism tries to maintain the illusion that the remote process is a local child to the parent process. Authentication of the user that owns the parent process is based upon the ability of the parent process to write a setuid file to the user's home directory and the ability of the child process to read the result.

The SPC API and associated control programs are private to the Common Desktop Environment. Actions represent the public API for running applications remotely.

Application Messaging

The ToolTalk Messaging Service is the application messaging mechanism for the Common Desktop Environment. Application messaging addresses inter-application control and cooperation for applications working on behalf of a single user. The ToolTalk session daemon is a local message-routing process whose control scope typically corresponds to that of the X server. This means that clients within a session issue requests, the ToolTalk session manager finds or starts some client within a session that is able to handle the request, and the ToolTalk session daemon tracks the request until completion.

The desktop provides two standard ToolTalk protocols known as messages sets. A message set contains a number of messages that can be exchanged between a sender and a handler process. These messages are grouped together because they describe related requests and notices. The sender and recipient may be within the same process or on different hosts. Message sets have associated utility functions that allow you to concentrate on the semantics of the protocol without getting involved in the low-level messaging details. Some of the message set functions enable you to defer to default behavior with almost no work on your part.

Desktop Message Set

The Desktop Message Set encompasses three areas. The first is windowing behavior. The second involves file access and short term file life cycle control. The third is specific to applications that have extension languages and is not generic enough to warrant library support.

Media Message Set

The Media Message Set allows an application to be a container for arbitrary media, or to be a media player/editor that can be driven from such a container. The Media message interface allows a container application (such as Mailer or File Manager) to compose, display, edit, or print a file or buffer of an arbitrary media type, without understanding anything about the format of that media type. ToolTalk routes a container's requests to the user's preferred tool for the given media type and operation. This includes routing the request to an already-running instance of the tool if that instance can best handle the request.

Data Typing

The Common Desktop Environment provides a uniform user interface to the objects contained on the desktop. To do this, the desktop has a mechanism, called data typing, to determine an object's type using a set of criteria. The criteria includes properties potentially shared by file-based and buffer-based objects such as name pattern and content pattern. Other criteria are exclusive to files, and include path-name pattern and file permissions. Associated with every desktop type is an extensible set of attributes, including icon name, name template pattern, list of actions suitable for presentation to a user, equivalent type names for other type spaces (for example, MIME type), and a textual description of this type. The actions and data-types database stores data criteria and data attributes.

The Common Desktop Environment defines, and platform vendors supply, a set of desktop type definitions. Your application should augment the database with both proprietary and public data types at application installation time.

Information is extracted from the actions and data-types through a Common Desktop Environment library API. The data typing API matches an object's properties with the database type criteria to determine the object's desktop type. The matching algorithm uses a set of precedence rules to resolve conflicts.

The Common Desktop Environment type space is defined by the X/Open Common Desktop Environment standard and exists primarily to support desktop-oriented activities such as icon display and action association. The MIME type space is defined by the Internet Engineering Task Force and exists to deal with exchange of mail message parts. A ToolTalk media type space exists in order to match data with handlers, and is a subset of X selection target types defined by the X Consortium. Thus, to do a complete job of type definition, you have to define a Common Desktop Environment type, X selection target, and MIME type. For private Common Desktop Environment types, append the type name to an organization's name. This partitions the name space without need for centralized allocation of types. The Common Desktop Environment claims the Dt prefix, for Desktop.

Method Invocation

A Common Desktop Environment type can be thought of as the class of a desktop object. Using this analogy, actions can be thought of as the methods available on instances of a class. Thus, the actions attribute in a type attribute list describes operations that are available for the type. A single action in the actions and data-types database has multiple parts, many of which are optional. These parts include:

• A description of how to invoke the operation: for example, through ToolTalk, through an execution string passed to the SPC mechanism, from within a terminal emulator, and so on.

• A description of the type of arguments associated with the action. The type of the desktop objects (files and buffers) that it accepts is defined by the actions and data-types database. Actions are polymorphic with respect to data types. For example, the Open action invokes a text editor for arguments that are text files and a graphics editor for arguments that are graphics files.

• A description of the number of arguments, if any, associated with the action.

• An optional indication as to where to carry out the operation: the local machine, a particular remote machine, the machine on which the executable resides, and so on. In addition, these execution locations can be included in a list so that if a host is not available then the next host on the list is tried. This provides a measure of redundancy that can be used to increase the likelihood of application launch, even in the face of remote host unavailability. Thus, actions provide network distribution guidance, implemented either through built-in ToolTalk facilities or through the SPC mechanism directly.

• An optional label, help string, and icon that the user sees when interacting with the action's GUI. These are hints to an application about how to represent the action to the user. These hints may be ignored, as the Front Panel does by ignoring the icon if the Front Panel configuration file supplies an alternative icon.

The collection of actions available to the user is assembled at the same time as the system is collecting type database information. In fact, related action and type information usually reside together in the same file. Desktop-defined, system-administrator-defined (host-specific), and user-defined files are assembled in order into a single (actions and data-types) database, with later definitions taking precedence. This ordering of search path precedence and traversal is used elsewhere by the desktop for such things as help volume and icon file searches.

The actions and data-types database and the File Manager use action files to instantiate actions as file system objects that can be viewed, invoked, moved, copied, and so on. The database contains references to an action's implementation (for example "run /usr/bin/app on machine net_app_svr"). However, a representation is needed of an action as an object that the user can directly manipulate. This is achieved by using an object's name, which identifies it as an action to any object manager that is looking for actions. Thus, if there is an executable file named Dtstyle and an action named Dtstyle, the File Manager will interpret that file, regardless of its content, as the Dtstyle action reference. In addition, the File Manager uses the action's label as the name that the user sees for this file. Action labels are localizable, whereas action names are programmatic entities that should not be localized.

The good feature about using files simply as pointers into the actions and data-types database is that the underlying implementation can evolve without the user having to do anything. However, one user's actions and data-types database may not match another user's actions and data-types database. Thus, a user cannot exchange an action reference, for example as a mail message attachment, and expect another person to have a comparable definition for that action. Exchanging a Desktop Korn shell script is the best solution to this problem.

Actions are useful because they integrate both legacy command-line applications and ToolTalk applications into the desktop as polymorphic, distributed operations on desktop objects.