Geoscience Reference
In-Depth Information
The software component stack has been a core concept of programming at least since the publi-
cation of Kernighan and Plauger (1976), systematising the experience of Bell Labs computer scien-
tists. They point out that modularisation and simplicity in coding lead to greater robustness, because
small functions and applications can be tested more thoroughly than large ones. Some of the lessons
are made clear in programming itself (Kernighan and Pike 1999), while others affect how one may
“glue” small utility functions together in an interactive and/or scripting language (Kernighan and
Pike 1984). In Bentley et al. (1986), McIlroy shows how Bentley's programming challenge - to
tabulate word frequency in a given text, solved elegantly in a monolithic program by Knuth - can
also be answered using a very short shell script using well-tried small utility programs available in
any Unix distribution.
Consequently, a software component stack can be taken as a sequence of component programs
that are used together to achieve a common goal. The most widely used example is LAMP: Linux,
Apache, MySQL and Perl/PHP/Python, comprising a sufficient and capable stack for running a web
server with server-side page processing. The languages used here vary, with applications written in
C, some C++, and bound together with shell scripts for administration, SQL for data handling and
a scripting language to process web pages dynamically.
As in a jigsaw puzzle, the interfaces between software applications in a stack need to be clear
and well defined. In the LAMP case and similar cases, the interface definitions were both clear
and stable, leading to the creation of a critical mass of system administrators and thus a sufficiently
large user base to generate a helpful flow of bug reports. Interfacing applications typically reveals
implementation assumptions that are neutral in nature in themselves, but when confronted with
unspecified assumptions in interfaced components may become problematic.
Using stacks of components becomes attractive when task objectives can more easily be met by
using components developed by others than by developing them independently. When the costs of
keeping a stack working exceed those of rewriting, the stack may fail, but this is seldom the case, as
reimplementation is fraught with difficulties, especially of ensuring a sufficiently large user base to
generate bug reports and to encourage other developers to join in.
Open-source software developers often advertise APIs, with an implicit promise that other
downstream developers using the API will be less subject to incompatible changes. This permits
them to make the improvements deemed desirable, or necessary bug fixes, without downstream
software being affected. Naturally, software closer to the user interface, or to the web server, will
often depend on underlying libraries and services, for example, for parsing XML. It is then vital that
changes in these underlying components do not change the way that dependent components func-
tion, unless their earlier behaviour had been in error.
Open-source software is characterised not only by frequent releases of components, and by rapid
bug fixing leading to patched releases, but also by the availability of checkout from version control
systems, permitting developers of “downstream” software to build and test against the current revi-
sions of “upstream” components where necessary, or at least before release, to attempt to future-
proof the “downstream” component. Build support systems, such as GNU autoconf, will then set
compile flags to indicate the versions of “upstream” components, and/or use will be made of self-
declaring version functions to branch on version internally.
Many of these issues have been influenced over recent years by the commissioning of specialist
support and customisation from open-source geospatial developers by customers or by the opening
of existing software codebases. Because large companies often need to integrate multiple software
components within specific quality assurance support systems, they contribute code, bug fixes and
contracted development which benefit all users of the components in question. The range of interac-
tion is large, especially because of the rapid growth seen in the use of geographical data.
Web, navigation and mobile geospatial applications have burgeoned in recent years, effectively
obscuring most of what the GC community has been concerned with over the past half century.
The vast majority of map applications do not include any analysis, and most users of the applica-
tions, and associated hardware and software, are scarcely aware that their searches, GPS-registered
