アプリケーションからアクションを実行する方法

デスクトップ・サービス・ライブラリによってエクスポートされたアクション実行 API は、アプリケーションから別のアプリケーションを実行したり、操作を実行したりするための方法の 1 つです。その他の方法として、次のものがあります。

• fork/exec システム・コール

• ToolTalk メッセージ

これらの方法は、それぞれ利点と制約があるので、具体的な状況を評価して、どちらが適切かを判断しなければなりません。

アクション実行 API の利点は、次のとおりです。

• アクションは、従来のコマンド行アプリケーション (すなわち、COMMAND アクション) と ToolTalk アプリケーション (すなわち、TT_MSG アクション) の両方をカプセル化できます。アクションを実行するアプリケーションは、コマンドがフォークされたのか、それともメッセージが送られたのかを知る必要はありません。

• アクションは多様性を持ち、デスクトップのデータ型機構と統合されます。これは、[開く] や [印刷] などのアクションは、与えられる引き数の型に基づいて異なる動作をするが、動作の違いは、アクションを呼び出すアプリケーションに対して透過されることです。

• アクションは、アプリケーション開発者、システム統合者、システム管理者、およびエンドユーザに対して、構成の大きな可能性を提供します。これらのユーザは、アクション・データベースを編集して、アクションの実行方法の定義を変更できます。

• アクションは、分散環境でも有効です。アプリケーションが fork/exec により別のアプリケーションを直接実行する場合には、両方のアプリケーションが同じシステム上で使用可能でなければならず、同じシステム上で実行可能でなければなりません。それに対して、アクション実行 API は、アクション・データベース内の情報に基づいて、どのシステム上で COMMAND アクションを実行するかを判断します。

• アクションによって、デスクトップの動作と常に一貫性のあるアプリケーションの動作が可能になります。これは、デスクトップのコンポーネントがユーザのデータ・ファイルを操作するときに、アクションを使用することで対話するからです。

  アクション実行 API の欠点は、戻り値機能が制限されている実行方法であり、実行されたアクション・ハンドラとの対話機能がないことです。これらの機能が必要な場合には、fork/exec/pipes を使用できます。ただし、共通デスクトップ環境 (CDE) で望ましいプロセス間通信の方法は、一般化されたクライアント／サーバ・パラダイムを持つ ToolTalk です。

  実行について説明します。アプリケーションがいくつかの異なる形式 (テキストとグラフィック) のデータ・ファイルを管理すると仮定し、これらのファイルの編集と表示の手段をユーザに提供する必要があると仮定します。アクションを使用せずにこれを実現するには、次の方法の 1 つを使用することになります。

• fork/exec を使用して、適切なエディタを起動し、ユーザがエディタの名前を指定するための何らかの方法 (環境変数など) を考えてください。このアプローチには次のような制約があります。

  • システム・コールによりサブプロセスを実行し、その結果のシグナルを監視する複雑なコードを書かなければなりません。

  • アプリケーションと同じシステム上で使用できるエディタが必要であり、システム管理者は、rsh などの機能を使用する複雑な構成を提供しなければなりません。

  • システム管理者とユーザは、アプリケーションの固有の構成モデルを学び、管理しなければなりません。

• ToolTalk メッセージを使用して、編集や表示などの操作をデータに対して実行することを要求します。このアプローチには、すべてのデータ型に対して使用可能な ToolTalk 形式のエディタが必要であるという制約があります。

アクションによりこれを実現するには、バッファまたはデータ・ファイルに対して [開く] アクションを実行するだけです。アクション実行 API はアクション・データベースに基づいて、送信する適切なメッセージまたは実行するコマンドを判断し、一時ファイルの作成や削除、必要なシグナルの取り込みなどのすべての詳細を処理します。