To some extent the container-component interface is the most important since it links the astronomical applications (components) to the environment. Thus, it must be utmost stable and support all relevant languages. Let us start listing some base requirements in two part namely:

1. What the container needs from the component:
   1. Some way to actually start the component. Since the container would like reasonable control just starting a separate process may not be enough. A standard 'start' or 'run' method is probably required possibly with some parameters.
   2. It would also be good the have some method to stop the component in an orderly manner but this is optional since one just can kill it. Also this and other such functions would required usage of threads or the like which may be too much to mandate.
   3. General information such as progress would also be nice but see above.
2. What the component needs from the container:
   1. The application obviously needs to get the parameters. The exact definition of these (in/out) will be a separate discussion.
   2. There must be a way to provide results back to the environment again.
   3. A general logging mechanism with levels (e.g. debug, info, ..., warning, error) must be available.
   4. A way with which the component can end in an orderly fashion providing a status
   5. Some environment information. If the actual application will not be threaded the exchange of information between component and container could be provided by a set of methods which sets/gets environment variables. Examples are: a) stop flag which the environment sets if it wants the application to stop itself. By checking such a flag in e.g. loops the task could the stop if requested. b) similarly the application could write progress information.
3. What other interfaces are needed:
   1. Data access methods which provides a homogeneous view of external data structures possibly with mapping of data models. One would hope that VO actually would provide most of this.

The question is then: what more do we need?

Several other features such as sending and receiving events, locking data, and generic interaction with graphics would be nice to have. We should list them but at this moment the issue is the minimum mandatory interface.

For several reasons, it would be nice if the specifications in the end would be compatible with distributed object concepts (e.g. CORBA) but also reasonable for a procedural programming model. In any case, we should first agree on the basic requirements and then look on how it could be implemented for different languages and programming models .

-- PrebenGrosbol - 30 May 2005
to top