KosmicTask is implemented using a multi tier architecture. This hierarchical design provides a stable and flexible environment in which to host and execute tasks written in a wide range of scripting languages. Each task runs as an independent process which prevents an error or failure in one task from affecting the behaviour of another. This approach also means that the various subsystems and technologies required to implement support for each scripting language can be kept separate.
The illustration above depicts two instances of KosmicTask on two machines communicating via a local network. Machine 1 is currently executing three tasks while machine 2 only has one active task. Two of the tasks executing on machine 1 are the result of task execution requests received from the local machine whilst the third is exiting as a result of a request received via the network from machine 2.
Each instance of KosmicTask distributes its operations over 4 distinct tiers each of which has a specific function. When task execution is requested information is passed down through the tiers, the task is executed and the task results are then returned via the tiers to the user. Task execution requests from the local machine and from networked instances are both dealt with in exactly the same manner.
The function of each tier is as follows:
- User Interface
- Users interact with the application at Tier 1 to create, edit and execute tasks. The actual operations of executing a task, accessing a task for editing and the saving of modified tasks is carried out by the task server in tier 2. The user interface tier does not need need to be running or displayed in order for the task server to be able to respond to network requests. The General tab in the Preference panel provides an option to run the task server at user login without displaying the user interface.
- Task Server
- The task server in Tier 2 receives requests from clients on Tier 1 to create, save and execute tasks. Client requests for all operations can originate either on the local machine or on a remote machine. If the remote machine requests a privileged operation the task server will require authentication from the remote user. Requests that relate to the creation, retrieval, updating and deletion of tasks are handled directly by the task server. When the task server receives a request to execute a task it responds by creating a separate task runner process in tier 3.
- Task Runner
- Each supported scripting language is implemented as an independent plug-in that encapsulates all the resources required to allow scripting in a given language. Each language plug-in also supplies a task runner that is used to execute tasks in that language. Whenever a task is executed the appropriate task runner is launched and then passed a copy of the task script to be executed. If the task runner can execute the task script directly it does so and then returns the task results to the task server in Tier 2. If the task runner cannot run the script directly then it launches a separate scripting subsystem that will directly execute the task.
KosmicTask supports both in and out-of-process scripting. Those scripts that run in-process (such as AppleScript and the Cocoa bridge components) are loaded and executed by the task runner in Tier 3. Scripts that are run out-of-process, such as the majority of the command line derived scripting components, are executed in Tier 4 as instances of individual scripting subsystems.
For example, executing an AppleScript task causes an AppleScript task runner to be created. This task runner can directly load and execute AppleScript code so no further scripting subsystem needs to be created. The Bash task runner, however, cannot directly execute a Bash Script, hence the Bash task runner loads a separate instance of the Bash subsystem to actually execute the task script.
The use of a subsystem is a convenient way of integrating an existing command line based scripting language into KosmicTask. In the case of the Bash script described above the subsystem is the Bash shell as supplied as part of OS X. In other cases, such as with the C and C++ language support, the subsystem is actually supplied by KosmicTask as part of the language plug-in.
Application Tasks and User Tasks
KosmicTask comes preinstalled with a number of general utility tasks known as Application Tasks. The majority of these are written in AppleScript. Application Tasks cannot be edited or deleted but they can be duplicated.
Tasks created by the user are identified as User Tasks. These can be created, edited and deleted by the user.
In KosmicTask each scripting language is implemented as a separate plug-in bundle. The application Resource Browser provides access to the resources supplied by each language plug-in. These resources include:
- A number of task templates (see below).
- A number of informational documents.
- A default list of property settings.
The informational documents generally provide links to web based sources of information for the represented language. A usage document provides an overview of how to accomplish basic tasks using the language. This document is intended to accompany and expand upon the information contained with the individual templates.
Each language also defines a default set of property settings. Most of these are read only and define the specific properties of the language plug-in. Several read-write properties also exist, such as the path to OS X scripting subsystems and task function and class names. These read-write properties can be overridden for individual templates and tasks. Selecting a property from the property list will display a short explanation of its purpose below the list.
In order to aid user task creation a number of task templates are available through the application Resource Browser. These templates serve to indicate the basic syntax required in each scripting language to achieve a particular objective. In general, all of the distinctive features of KosmicTask are available as a template in each scripting language. Each template includes the script code, the settings necessary to configure the script and an informational document.
Often the best way to find out how to accomplish a particular task is to examine the available templates. The simplest template, named Hello Kosmos, simply returns Hello Kosmos! and is analogous to the classic hello word program that is normally quoted as an introductory code sample. Other templates indicate how to return complex objects and files as results while others detail features such as class creation and application automation.
In addition to the templates that are supplied with the application (the Application Templates) the user may define any number of additional templates.