In a slight variation on the Deich/Noordam proposal, I would like to
distinguish the following elements in an application:
The command and control interface (CCI)
The data interface (DI)
The interactive control interface (ICI)
The generic application code (GAC)
The CCI sets the application going and gives it the input parameters
it needs. One obviously needs a common data model and a standard DI
to it; I would consider this the most critical component. Possible
models to look at are the Aips++ table classes or the Khoros-2 data
model. The interface should be transparent as far as data source is
concerned; the application does not have to know whether the data come
from disk, socket, shared memory, stdin, or anyplace else. Note that
the important thing is the interface (or data model), not the data
format itself; one could envision a single implementation of the
interface to be able to work with more than one data format (say,
FITS, HDF, ASCII). Rather than incorporating interaction and display
into applications, I would prefer to put that functionality in
separate processes, or, at least, in separate classes. The ICI allows
(also user-provided) applications to communicate with such supporting
processes in a simple and painless way. The ICI can also be used by
those display and interaction tasks themselves, for their control.
Finally for the GAC, when I say "generic", I mean "generic. The
application code should not contain anything that is bound to any
specific environment.
I can see two appraoches to designing such a system. One is
completely object-oriented, hiding all the ugly details in a toolbox
of classes that provide clean and generic interfaces. The other is
the use of code generators. A combination of the two may well be the
best way to go.
In the OO approach, an application would consist, at its highest
level, of a GAC object that communicates with a CCI object, optionally
one or more DI objects, and optionally with one or more IC objects.
It's clean, it's simple, it's attractive. It is also very flexible
and very open, and can be incorporated into any environment that has
an implementation of the CCI, DI, and ICI classes. It is easy to hide
different data formats befind the DI class and different windowing
systems by selecting the correct display task, as long as its speaks
ICI.
In the code generator approach, the application programmer has to
provide the GAC in the form of a generic function (subroutine) and a
specification of the input and output parameters; the GAC contains
standard calls to DI and ICI. The code generator for a particular
environment wraps all other necessary code around the GAC to make it
work in that environment and makes a Makefile. This is the technique
used by Khoros. I found this a very useful concept, since it allowed
me to write just the generic code, let the code generator worry about
the dreary stuff, and have access to all other useful Khoros modules,
while at the same time being able to port the application very
painlessly to other environments. I described these efforts in ADASS
II, p. 194.
A combination of the two approaches might be very promising. Use the
OO approach to ensure clean interfaces and great flexibility. Let the
application programmer just write the GAC class, and use an
environment-specific code generator to create the compilable code and
whatever supporting things (e.g., parameter files, Makefiles) are
needed.
It would also be good to look around in the rest of the world, lest we
keep reinventing the wheel. I would be very hesitant to turn to
commercial products, but there is a lot of interesting stuff in the
public domain and associated areas. Khoros is one example. One wants
something that is freely available to one's users; for which one can
get the source code; and that has an active user community.
As far as operating systems are concerned, I would suggest to stick
with POSIX compliance whenever practical. PCs shouldn't really be a
problem since it's so easy now to run them under Linux :-)
- Arnold Rots
Arnold H. Rots XTE-GOF
| Laboratory for High Energy Astrophysics / USRA
___ |___ ___ Code 660.2
___|| || NASA / Goddard Space Flight Center
|___|| || Greenbelt, MD 20771
USA (Bldg 2, W20F)
arots@xebec.gsfc.nasa.gov +1 301 286 1061 Fax: +1 301 286 1684