All of the above features result in cost and time savings. However, most of
them are merely side-effects of what is in my opinion the single really
interesting feature
of the dashboard, which is its symbiotic relationship to a knowledge base
embodied in an online database. In most Tcl/Tk applications involving databases,
the database is the target of the application; i.e., the information in
the database is manipulated by the application. In my ``fosql" Tk forms GUI
for Sybase, the forms designs themselves were stored in Sybase tables, and
the data in the primary forms design table could be edited using the form
for that table. However, the target of the fosql application was still the
data in the rest of the database.
In the ``Dashboard" application, the database is not the target of the app;
the telescope, dome, and instrument and the data gathered by the instrument
are the target of the app. The database is an intrinsic part of the
application itself. It contains ``information about information", or ``meta-data"
which the application uses to configure itself and to make certain inferences
about its own function. This could be seen as one way of implementing
object orientation; a database is the ideal way of representing objects
and their attributes, and the code is merely the methods which apply to
the objects. We could also regard the database as the equivalent of
hundreds or thousands of C source ``structs".
Many other applications, such as mail tools, use resource files of one kind
or another to configure themselves, thus avoiding recompilation across
changes of appearance or function; but in general, each application has
its own resource file which is not shared with any other applications.
(The X resource database is one exception, being a true online database
with a known API, but most X clients have private resource files applicable
only to their instance or their class.)
In contrast to the ``private resource file" model,
a central authoritative body of knowledge about the information on which the
application operates - implemented as an online database - forms a conceptual
hub about which many applications (such as the dashboard) can be
constructed with maximum generality at relatively low cost. The tedious and
repetitive type of tabular information which (in our older control systems)
is replicated many times in different C sources, vxWorks sources, etc. is here
available in one consistent place, accessible online. (It can be cached
as FITS files or other ASCII formats in case we lose access temporarily to
the live source.)
I should perhaps note here that as well as keyword syntax and semantics,
overall system design is also expressed in our database as tables of hardware and
software ``agents," which pass ``keyword" information between them in various
formats and media. Using the digraph tools from Lucent Technologies [Dot]
we can easily generate information flowcharts for the hardware and software
subsystems. Thus the majority of our project design information is online in
a highly standardized, codified, machine-readable form; this in turn means
that 80 percent or more of our project documents are auto-generable.
The logical conclusion of this conceptual strategy is
that design, documentation, and by inference a certain percentage of
generable source code, are all manifestations of one body of knowledge,
expressed once and maintainable at one central point.
All the usual reasons for choosing Tcl/Tk apply: speed of prototyping and development, low cost of modification and deployment, portability, lack of commercial restraint on distribution. However, there were certain project-specific reasons as well. From prior experience I had already become convinced that Tcl(X) was a near-ideal language for database applications (largely because of its typelessness and its solid list processing features). Lastly, because of the eval feature combined with the above, it is remarkably easy to write self-configuring multi-purpose applications in Tcl (using methods which have no equivalent in C or other compiled languages, such as the dynamic generation of variable names and on-the-fly generation and execution of code). The ``Dashboard" application was a logical outcome of previous positive experience with Tcl and its extensions.
So far, we feel that the ``Dashboard" application has been a Tcl success story.