Version 1.9 Build 1367

News	FAQ
Search	Home

Next: Some Development Plan Items Up: Note 186: The Tasking Environment of AIPS++ Previous: Control Hub

Subsections

Standard Environment

The control hub and related structures are implementation details -- they impose no structure for the user to operate in. This section describes the standard environment that the user operates in.

The system described here has the following elements:

1.: An object chooser for browsing data objects
2.: Various type-specific browsers (e.g., aipsview, table browser) which can be launched from the object browser.
3.: A task-launcher for objects and tasks which act on data.
4.: A CLI for ad-hoc calculations, high-level programming, and command-line control of objects (the CLI must be bound to the object system). Note that the CLI is a separate process from the control hub, and it need not be the same language.
5.: Log and progress monitors.
6.: A context-sensitive⁷ help and online-documentation system.
7.: Various objects to allow CLI-users and other programmers access to data and computations that it would be inconvenient to reproduce in the native language.
8.: A workspace in which the user may conveniently group data and task objects.
9.: A parameter database which acts both to save user defaults for parameters, and to act as a clipboard for selections (e.g. an Image BLC,TRC).

In brief, I would describe this model as data-centric and moderately coupled.

Note that GUI related issues are outside the scope of this paper, although they will be important for the adoption of this system.

AIPS++ Browser

The Object Browser is used to find data and tasks (although to the user they appear in different GUI's). Thereafter it is used to activate operations on the data, and control for the tasks.

class aips_browser {
public:
    Bool add_package(String package_name);
    Bool remove_package(String package_name);
    Vector<package_description> active_packages() const;

    void current_data_directory(String &alias, String &path) const;
    Bool change_data_directory_to_path(String path);
    Bool change_data_directory_to_alias(String alias);
    void rescan_directory();

    void show_all();
    void set_name_filter(String show_it_match_this_pattern);
    void set_type_filter(Vector<ObjectType> hide_these_types);

    Vector<ObjectID> select_objects();
    ObjectID launcb_task_control();

    set_viewer(ObjectType type, String server_executable);

    // e.g. so you can follow one set of directories with a different browser
    ObjectID clone() const;
};

Tasks

Computational applications which only require modest levels of interaction are called tasks for historical reasons. The model here has the following features.

1.: Tasks parameters are saved in a database, and can be context sensitive (``in VLB mode, you have to set these parameters as well''). Task parameters are inherently local, although defaults may be copied from database if desired.
2.: Tasks which require it can have (or require) interactive updates to some parameters.
3.: Tasks may be rerun with from an initial set of parameters. A task writer may allow a task in which parameters are updated during execution to be rerun as well.
4.: Tasks produce log messages, progress events, and can provide context sensitive help.
5.: Tasks can be started from the Host OS shell.

Parameters are named values required by a task to execute. The values may be of type scalar, array, enumeration, parameter set (hence they are hierarchical), ObjectID, or decision. A decision type is an enumeration that is used to select further parameters. Parameters, as well as their allowed and default values, are mapped into a Record.

Besides a name, each individual parameter might have a parameter type. These types are common to all tasks, and are analogous to the known structures, however they need not be of record type (e.g., it could be an ``alias'' to a String''). These types are used by the parameter database, and are useful for documentation (a ``file name'' instead of just ``string''). Each parameter type has a help pointer.

A task has one parameter set which is used to initiate execution. Ongoing execution of the task is controlled by parameters as well. Those parameters will usually be different (more restricted) than the initial parameters. The parameters are fundamentally obtained from the task at run-time, although they can be cached externally for efficiency and browsing purposes.

Parameters may be stored in a parameter database ``by task'' - with multiple named versions. Defaults for particular parameter types may also be stored.

For an arbitrary object, the ``type'' of the task parameter will be its name. This implies that parameter names should be chosen with some care; in particular they should be the same across classes when their purpose is the same.

Task Activation and Control

Task activation follows a particularly simple protocol:

class task {
public:
    Bool go(ObjectRef<task_controller> controller, Bool block);
    Bool shutdown();
};

The task controller, which is queried by the task, is a more interesting class:

class task_controller {
public:
    // Common services and information that may be of use to the task
    Int                          desired_log_level() const;
    ObjectRef<log_sink>          log_displayer();
    ObjectRef<help_viewer>       help_displayer();
    ObjectRef<progress_monitor>  progress_displayer();
    // These are object-ID's rather than references to prevent unnecessary
    // linking
    ObjectID image_displayer_id();
    ObjectID plot_displayer_id();
    ObjectID table_displayer_id();

    Int demand_parameters(const Record &paraform, Record &set_parameters);
    void set_update_paraform(const Record &paraform);
    Bool have_update() const;
    Record get_update() const;

    Bool have_replay() const;
    void replay(Vector<Record> &stored_parameters, 
                Vector<Int> &sequence_points) const;

    // Use for hints, like memory use
    Record environment() const;
};

Note that this protocol allows the ability for a task to ``replay'' itself, even if task parameters are modified while the task is running. This is implemented by the task emitting a ``sequence number'' whenever its parameters are changed (these numbers need not be consecutive - they will often be associated with an algorithm parameter, e.g., iteration number). When a replay is desired, the sequnce numbers are provided along with the sequence of stored parameters.

Standalone Tasks

It is often useful to be able to run ``load and go'' tasks from the host operating systems command line, and not requring a running control hub, etc. This is accomplished by the run-tim-system providing a local task controller which fills in parameters from command line arguments, and returns local objects which print to standard output for help, logging, and progress monitoring. The other object services, like image display, are null.

Service Objects

These are objects which are provided for the user to manipulate directly, often from the command-line interpreter. They fall into the following categories:

Data exploration: These objects will be typically be attached to a GUI. They are not only used to view the data, but to interactively get selected parts of it (e.g., a table column, or a subset of points to use for continuum subtraction), and possibly to change values as well. Initially we will require objects for tables, 1D graphics, and 2D+ graphics.
Computation and algorithms: The computations and algorithms which are available to the C++ programmer should also be made available to the CLI user through computational objects. Normally the same executable would serve both the application and its unique computations.
Persistent data: The user must be able to manipulate persistent data. At a minimum, this means he must be able to read and write tables, since by edict all AIPS++ data, with the exception of user initialization tables, is accessible through the table interface. An additional interface for the Image will probably be required. Note that system databases (e.g. leap seconds) are merely table objects that have a known name in a standard directory.

It must be emphasized that these services are being provided directly for the end user. They should generally posess fairly simple interfaces. I would suggest that the interfaces should be approved by potential users.

Next: Some Development Plan Items Up: Note 186: The Tasking Environment of AIPS++ Previous: Control Hub Contents