A last comment on futures...

Dr James Coggins (coggins@cs.unc.EDU)
Mon, 16 Oct 1995 21:21:06 +0100

I'm beginning to get things together for my trip to Tucson,
so this will probably be my last chance to contribute to this
discussion before ADASS V.

1. On Scripting Languages

I was thinking about scripting languages for my ARCTIC distributed
computing environment when it hit me: with an appropriate
communication library and a simple convention for defining the
capabilities of server modules, my scripting language can be C++!

The capabilities of a server are defined by a C++ class definition,
instantiations of which are proxies for (remote) server processes.
The constructor creates a proxy object that establishes a connection
to the command port of a (possibly remote) server process. When I send
a message to the proxy it forwards the message to the remote server,
causing something to happen.

Thus, servers (ICEbergs) are distributed modules that use a
powerful, domain-specific support library. Control modules (ICEcubes)
are distributed modules that use a simple communication library
to cause the ICEbergs to do things.

2. On Standards

The amazing degree of cooperation in the astronomy community that
led to FITS might happen again in other areas, of course, but it would
be wise for the community not to count on it. It should be possible for
someone who wants to define a collection of data to do so by providing
to the community a server to read that data and provide it over the
network to all requestors. It should be possible for data standards
to be established in any subcommunity interested in some data by
communicating the code required to read/write/send/receive that data.

This approach simplifies matters in several ways: you don't need
universal agreement to establish a useful standard; the amount of
formatting information you need to agree on is smaller and more
specific to the subcommunity; the standard is already embodied in the
code that manipulates the data; different agreements about how to
augment or transform the data can be made and implemented by different
subcommunities without interfering with standards established by other
subcommunities.

3. On Monolithic Packages for Unique Resources

A monolithic package might be the right way to provide shared access
to unique resources (a unique database, a controller for an
instrument). I'd prefer that "monolithic" not become in our
discussion a synonym for "bad".

-- 
Dr. James M. Coggins
Associate Professor & Associate Chairman for Academic Affairs
Department of Computer Science  E: coggins@cs.unc.edu
University of North Carolina	V: 919-962-1738    F: 919-962-1799
Chapel Hill, NC 27599-3175	W: http://www.cs.unc.edu/~coggins/