Subject: Invitation to a preliminary email discussion,
prior to the BoF session on "Software Futures"
Dear ADASS'95 Registrant,
You may have seen in the preliminary program that ADASS'95 has a
separate `BoF' session on "Software Futures", which we interprete to
mean "The Future of Astronomical Data-analysis Software", or FADS.
This session will be held on Wednesday at 4:30. We are hoping that
with this call for participation, followed by time to have informal
interactions during the earlier part of the conference, we will be
able to have a lively discussion on Wednesday afternoon.
Discussions about the Future descend easily into meaningless babble.
Although we enjoy that as much as any other software person, it would
be a pity to waste this opportunity. After all, ADASS is the de-facto
worldwide forum of our specialised community. We have the ambition
that this BoF should produce some tangible results, i.e. results from
which this community can profit within the next 5 years. In order to
achieve a fruitful BoF, the ground must of course be prepared beforehand.
Therefore, we would like to invite you to take part in an email
discussion between now and the start of ADASS. We have set up an email
`exploder', and we have prepared some proposals that can serve as a
starting point. To join the discussion, please send a mail message with
"subscribe" in the body to
fads-request@nfra.nl
Of course, this BoF has no monopoly on the Future, and where possible,
we will also endeavour to incorporate relevant points about FADS that
are made by speakers at other ADASS sessions, and by poster presenters.
======================================================================
Kickoff proposal
At this moment the user can choose between various large, monolithic
packages. Each of these contains a collection of useful routines, which
might or might not cover the needs of the user. These routines are
packaged in a much larger body of code that deals with task control,
user interface (UI), data storage, visualisation, etc, etc. Usually, all
this peripheral stuff has been re-invented especially for the package.
Such `megalithic' packages are increasingly difficult to maintain (let
alone create) by a single group, especially in the face of rising user
expectation in the area of user interface, distributed processing,
linkage with other packages, etc. Clearly, there is a problem.
There is one clear advantage to a monolithic package: it can offer a
unified, consistent, and familiar (after some use) interface. Users
don't want to leave a familiar interface to run a new task written under
another package, and why should they be forced to?
We contend that the technology exists to create a system which combines
a maximum in healthy competition in terms of algorithms with a minimum
of duplication in terms of the peripheral services. The key lies in
collaboration and specialization, which is only possible if our
relatively small and specialised community is prepared to adopt some
minimum standards.
We propose to adopt standards -- standards that can be retrofitted
to existing packages as well as new ones -- that will let a user
* run a standard-conforming task from any standard-conforming UI;
* switch to a new and better UI without giving up the set of tasks
with which s/he is intimately familiar and wants to continue to use.
The industry will, within a few years, provide the mechanism (e.g.
CORBA) to bind at run-time objects that have been developed completely
independently. This mechanism will come free with the hardware. But
the industry will NOT provide the standard interface for our particular
community, e.g. image, coordinates, table, etc. Consequently, if we do
not wish to be locked into monolithic packages forever, we will have to
define such a standard interface ourselves eventually. The question is
when, and how.
The standards that we would see established are listed below. They can
be worked on independently, although they do form a natural unit that
ideally should be developed as one:
a) A standardized protocol for low-level portable objects, like CORBA.
(Ideally, we should adopt the one that is going to win in the
larger commercial market.)
b) Source-code interface: There will have to be several language
bindings for standardized task interfaces: (i) at a guess, C++
will be essential because CORBA will probably be at the bottom of
the implementation, and it has only got a C++ binding at the
present; and (ii) Fortran and C, because they are the languages of
the vast majority of existing tasks.
c) Library level (relink): Adopt a standard packages interface/API
and implementation.
d) Disk files: a standard for representing common data structures
on disk.
THE QUESTION: Should there be an ADASS initiative to define such a
(minimum) standard? ADASS is a better worldwide forum for this kind
of thing than the IAU, since it is less official (and thus faster),
and much more knowledgeable. For instance, the POC could set up a
Standards Committee with the assignment to report to ADASS`96.
The proposed standards make it possible to put together any number of
'packages' from the available modules. For example, by using the new
standards, IRAF's layered packages would become available to the
astronomical community beyond IRAF, and in turn IRAF would benefit from
tasks that were originally developed for other packages.
NB: A standard will only be useful if the existing large
packages will commit themselves to use it as an upgrade path.
NB: Even if industry settles on an implementation standard for portable
objects that turns out to be different from the one we choose, (CORBA,
in our running example) it will still be easier to adapt the existing
software if it already conforms to a single standard.
NB: If the standard is a success, and everyone will start contributing
cunning algorithms, there will be a tidal wave to manage. This will be
healthy competition, but with an acceptable level of duplication.
=========================================================================
If you like these ideas, we would like your collaboration in this Email
discussion to flesh them out into something more tangible. If you do
NOT like them, or if you think other ideas are more important for wide
discussion among the BoF attendees (BoFfers?), please offer alternative
proposals. In any case, do not forget that these issues will very
likely have an impact on you and your career, in one way or another.
We look forward to your reactions, whatever they are. We hope for a
lively discussion, and will try to summarize and stimulate the
discussion every 2-3 days, depending on the traffic. The only thing
that would discourage us is your silence.
Jan Noordam
Will Deich