We are pleased to find fairly widespread interest in the FADS mailing
list, but are disappointed that so many have come only to listen without
contributing their own thoughts, or at least some reactions. You might
want to take note of the following statistics. At this writing, the
FADS mailing list has:
Subscriptions: 54
Original messages: 5
Replies to other messages: 1
Level of excitement on a scale of 1 to 10: 2
The specific idea behind the FADS list was to discuss the likely future
of astronomical data analysis packages in the next decade, and to
decide whether a collaborative effort across the astronomical software
community could be helpful. If so, those present at the BoF session
could pass a resolution for community action. But we cannot
realistically expect to be very focussed at the BoF if there isn't an
advance discussion.
In order to help things along a bit, we will distribute our own draft
resolution in the beginning of next week. Any advance suggestions are
welcome and will influence the draft.
(Note: if you want a copy of the current subscription list, mail the
message "send who" to fads-request@nfra.nl . For a digest of the
previous contributions, mail the message "send digest".)
We are attaching a short summary of the mailing list contributions to
date, in the hope that some more of you will feel stimulated to write.
-Will Deich
Jan Noordam
======================================================================
Herewith a summary of the modest discussion that has gone on so far.
Please note that the summaries are not provided by the original authors,
and they may contain errors of understanding or omission -- don't
attribute anything below to the original authors!
===============================
One-line summaries:
Rahim Choudhary: How do we add new s/w technology to legacy s/w packages?
Elwood Downey: Don't waste effort on unnecessary portability standards.
James Coggins: A new arch reduces need for large base library, data standards.
Karl Glazebrook: Future s/w should have hooks to external scripting languages.
Will Deich & Jan Noordam: Separate the U/I from the task; make tasks portable.
===============================
One - two paragraph summaries:
Rahim Choudhary: How do we add new s/w technology to legacy s/w packages?
Found that an object-oriented development for a new system
could not easily fit into the tools already developed. The BoF
should address the issues of facilitating technology insertion
despite the problems posed by legacy systems.
Elwood Downey: Don't waste effort on unnecessary portability standards.
Existing standards (whether de facto or otherwise) such as
POSIX, X-Windows + Motif, RPC, sockets API's are likely to be
available for a long time because current marketing emphasis
will resist devoting resources towards changing them. Therefore
these forms should be used directly in new programming efforts,
and there is no need for an artificial portability layer.
New scripting, tasking, GUI, and IPC mechanisms are _not_ needed;
future efforts should be directed towards adding the real value:
defining the file, message and object formats needed for data
interchange and the algorithms.
James Coggins: A new arch reduces need for large base library, data standards.
Has tried shared class libraries to replace monolithic packages,
but the libraries are too large and have become inconvenient.
Now implementing a distributed system architecture (ARTIC) to handle
problems of: the excessively large base library; the difficulty
of reaching standards agreements over a large, diverse community;
the need to disseminate bodies of code while maintaining control
over it during the rapid maintenance updates; and the need to
provide access via Internet to unique resources (e.g. instruments,
specialized algorithm implementations).
The plan for the ARCTIC environment sidesteps the issue of data
standards.
Karl Glazebrook: Future s/w should have hooks to external scripting languages.
Scripting is a major area that hasn't been mentioned. Scripting
languages built into monolithic packages don't offer the features
that one can find in a general purpose scripting language such
as Perl. Solution: provide hooks into the applications from
languages such as perl or tcl or their successors. Likewise
there must be the ability to treat applications-written-as-scripts
as bona-fide applications in there own right.
Will Deich & Jan Noordam: Separate the U/I from the task; make tasks portable.
Large monolithic packages offer a consistent user interface,
but their bulk has gotten out of hand -- they are hard to manage,
maintain, and distribute. To alleviate this, user interfaces
should be separated from the tasks they execute. Tasks should
conform to a set of standards that let them be executed by any
conforming user interface. On the one hand, users could run new
tasks from their old interface; on the other hand, users could
run trustworthy older tasks from a newly-developed, better interface.