Galaxy Communicator Documentation:

New Features in Version 3.x

License / Documentation home / Help and feedback

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.


License / Documentation home / Help and feedback
Last updated January 4, 2002