This is a subject that is of some interest to me since we have identified
`distributed objects' to be the core of our (AIPS++) runtime environment. [We
are in the process of changing its implementation, from a message passing
interface fairly tightly coupled to the Glish `control bus,' to a more
object-oriented system which is separable from Glish, although the initial
implementation will be on top of it.]
As I see it there are two main issues to consider, one technological and one
(at least partially) sociological.
1 Base Technology: If our objects are going to interoperate, they need to be
built on top of the same communications/control/... mechanisms. What is it?
Do we adopt a commercial `standard', or roll our own?
The commercial situation is not a happy one. CORBA/SOM/OpenDoc/... is fairly
nice technologically, but it is not clear at all that the technology is going to
be successful. COM/OLE doesn't have a particularly nice object model (no
inheritance), and it's not clear whether it's going to be important in the UNIX
marketplace (moreover, it's not clear whether UNIX will be continue to be
dominant for astronomical data processing).
If we roll our own, we probably lose some performance and robustness. Even
worse, we might end up with an astronomy `standard' which is roundly ignored
when the industry standard does shake out. Remember IDI?
2 How do the basic interfaces get defined?
While we all have our `internal' objects that cannot have standardized
interfaces, we must also have a standard library (one purpose of a standard
library is to allow other separately developed software components to
inter-operate - recall how tedious it is to use different libraries which merely
have a different notion of a string). I imagine that we would at least want to
standardize on the following areas:
o Basic types (e.g. do we have an inhomogeneous Record type)
o Data access - at least images and tabular.
o Line and Image graphics.
o Task interaction.
Defining these interfaces so that the different sub-communities would be
satisfied will be difficult. We would need to be more nimble than a standards
body, and willing to make accommodations in various cherished views of how a
data processing system should work, and then engineer the solutions into our
software.
What is driving us to make this effort?
To summarize:
o I'm not sure if a good technological base exists yet; and
o I'm not sure if there's enough desire (== perceived benefit)
in the various software groups to define the common interfaces.
Brian
--
Brian Glendenning - National Radio Astronomy Observatory
bglenden@nrao.edu Socorro NM (505) 835-7347