Galaxy Communicator Documentation:
New Features in Version 3.x
The major purpose of this distribution is to clean up the installation process
and move servers over to the new open source toolkit.
Improved installation process
We have moved the entire configuration process
over to GNU configure, a migration which began in version 2.0. As an added
benefit, we've been able to compile and test the infrastructure easily on
three additional platforms: SGI IRIX,
Intel FreeBSD, and MacOS X/Darwin.
We have introduced Hub
continuations, which allow the programmer capture new messages from servers
and treat them as replies to previous messages, in order to reconcile conflicting
(asynchronous vs. synchronous) programming models.
Open Source Toolkit
Version 3.3 marks the debut of the Open Source Toolkit (OSTK), which we
hope will become a must-have collection of servers and wrappers for dialogue
system development. We have initially populated the Open Source Toolkit with
our own servers and wrappers, including some previously unreleased software.
The OSTK is available from http://communicator.sourceforge.net.
Experimental Hub visualization support
In this version, we're releasing experimental work in progress to support
message streams which report Hub state to separate servers, for visualization
or other monitoring. See the -gui
command line argument of the Hub executable. A corresponding experimental
Hub visualization tool can be found in the Open Source Toolkit.
The major purpose of this distribution is to add a new, improved tutorial
to the reorganized documentation.
In the past, MITRE has held training courses on the Galaxy Communicator
architecture, and provided a self-guided version of the training materials
for download. These materials had fallen out of date, and were no longer
being distributed. In this new version, we've completely updated the tutorial,
integrated it into the main documentation, and redesigned it to be
more consistent, easier to run, and easier to understand.
Improved unit tester
In support of the new tutorial, the unit tester
has been completely redesigned and reimplemented. It now allows you to connect
to a Hub pretending to be a server, or to a server pretending to be a Hub.
It also provides a graphical interface to allow you to respond to incoming
messages and to send new messages of your own, and keeps a mouseable history
of frames for you to select from if you choose.
This version is mostly a bug fix distribution, but there is also some new
functionality provided. For details, see the release notes.
New Builtin server functions
The Builtin server now has functions
to list the available servers and to call subprograms so that they return
This version includes experiment support for cross-compiling executables for
other platforms, such as the StrongARM.
This version provides a new abstraction for the event-driven programming
model used to embed Communicator
servers in external main loops.
Hub scripting improvements
The Hub scripting language has a new
directive (IGNORE:), a new comparison (IN), and better write-locking for
the global namespace.
In versions 2.1 and previous, there was poor support for session management.
For instance, if you wanted to send a new message to the Hub in the current
session, you were required to add the session ID to the outgoing message
by hand. This requirement was even more onerous in the case of sending messages
from timed tasks and broker callbacks. Also, the Hub created sessions for
new session IDs in an odd, inconsistent set of circumstances. These problems
have been fixed. The Hub now always creates a session if it doesn't know
about it, and we've implemented far more robust session management
In versions 2.1 and previous, once the Hub sent a message to a server, the
server was busy, as far as that Hub was concerned, and it could send no more
messages to it until the server responded. This sometimes led to deadlock
situations. In version 3.0, you can use continuations to
tell the Hub that you'll send an answer later.
Server location files
In versions 2.1 and previous, it was hard to reassign ports and host locations
for a configuration of servers. The -locations command line Hub
argument helped, as did the -port and -contact_hub command
line server arguments. However, there was no way to change who contacts whom
without editing the program file, and the command line arguments were quite
unwieldy. In 3.0, you can define a server locations file which
the Hub and all servers can refer to via the -server_locations_file
command line argument, which specifies the location of all listeners and who
contacts whom. These settings override the Hub program file, so no program
file needs to be edited.
Before version 2.0, there was no support for distinguishing between Communicator
releases. This was a potential problem in source code which needed to be
compiled against multiple releases. The GC_VERSION C declaration was introduced
in version 2.0, but it was not documented, and there was no corresponding
support for Python, Allegro and Java. In 3.0, we've documented
this feature and made it available
in Allegro (compile/read time feature) and Python (run-time variable). Java
is a compiled language which has no compile-time conditionalizations that
we can find, so this feature is unfortunately unavailable in Java.
Multiple events in C timed tasks
In versions 2.1 and previous, the implementation of timed tasks in C did
not allow you to associate a single task with multiple events (input available,
error input available, etc.). In version 3.0, the functions Gal_AddTaskExtended
support this functionality correctly.
C frame library improvements
Version 3.0 features three major improvements to the frame library. First,
you can now create dynamically expandable lists and binary data objects (see
the functions Gal_CreateListObject
for example). Second, we've defined a parallel API which gives you better
memory management control over objects (see the Gal_Create... family of functions).
Finally, there are no longer any restrictions on the types of objects you
can insert into frames; all array types can now be sent, in addition to binary
data (see the function Gal_CreateInt16Object,
Improved event-driven programming model
In version 2.1 and previous, there were functions which allowed you to register
"callback" behavior (for instance, when a broker was destroyed), but there
was no consistent event-driven model underlying these functions, and the
implementation was quite incomplete. In version 3.0, we've defined an event-driven
model which we use for the default Communicator main loop, for event registration
in external main loops, and for embedding the C library in the Python and
Allegro bindings. See the upgrade
notes for more details.
Improvements in the Hub syntax and conceptual model
In a number of circumstances, it's important to be able to exert control
over how and when particular servers are used by a given Hub. In order to
support this degree of control, we've reorganized the Hub model of its resources.
The Hub now groups servers (known to the Hub as "service providers") into
equivalence classes of service
types. These providers can have properties associated with them, and the
Hub programmer can impose conditions on the choice of provider, based on
the service provider's properties and the properties of the current session
These improvements are accompanied by a new extended syntax mode,
which broadens the range of expressive possibilities and eliminates some
of the idiosyncracies of the default Hub syntax. The primary improvement in
extended syntax mode is the ability to refer transparently to session variables,
global Hub state, server properties, etc.
Finally, the Hub now has greater debugging and error-handling support,
including expanded functionality for the -debugHub command line argument, introduction
of the ERROR: Hub program directive,
and the new Builtin server dispatch functions hub_break, hub_exit and hub_print.
In version 2.1 and previous, the set of types which could be brokered and
the set of types which could be included in frames overlapped, but were not
identical. In 3.0, thanks to the new unified XDR encoding, there is finally
no distinction between these sets. Also, outgoing brokers now accept multiple
subscribers by default.
The interaction between Hub and servers has been made more robust in a number
of ways. First, the new XDR encoding has eliminated a number of nagging bugs,
such as the inability to send arrays of floats from one platform to another.
Second, both Hub and server indicate in their messages whether a response
is expected or not, and the Hub and bindings either eliminate responses or
add pacifier responses to guarantee that the expectations are fulfilled.
As a result, the Hub will no longer deadlock waiting for a response from
a server which isn't configured to provide one. Third, the infrastructure-specific
data is now encapsulated in a single frame key, which will make upward compability
much simpler in the future. And finally, the initial protocol handshake now
contains a version number.
Last updated January 4, 2002