Galaxy Communicator Documentation:
New Features in the Current Distribution
Version 3.3
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.
Hub continuations
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.
Version 3.2
The major purpose of this distribution is
to add a new, improved tutorial to the reorganized documentation.
New tutorial
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.
Version 3.1
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 values.
Cross-compilation support
This version includes experiment support for
cross-compiling
executables for other platforms, such as the StrongARM.
Embedding support
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.
Version 3.0
Session management
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 support.
Continuations
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.
GC_VERSION declaration
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
and Gal_TaskPkgRunReasons
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
and
Gal_CreateBinaryObject,
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,
for instance).
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 and token.
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.
Brokering improvements
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.
Protocol improvements
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.
Please send comments and suggestions to:
bugs-darpacomm@linus.mitre.org
Last updated January 4, 2002.
Copyright (c) 2000 - 2002
The MITRE
Corporation
ALL RIGHTS RESERVED