[Communicator-user] Impending release announcement and future plans

[Samuel L. B. <sa...@mi...>]

[Apologies if you get this message more than once; I'm trying to cover
as many lists as possible, and they have considerable overlap.]

All -

I wanted to update you on our current plans for the Galaxy
Communicator distribution, and seek your feedback on upcoming
releases.

Galaxy Communicator 3.2
-----------------------

Sometime in the next two weeks, we'll be releasing the first beta of
GalaxyCommunicator 3.2. The reason for this new release, in addition
to the usual bug fixes, is that we're finally resurrecting and
completely redesigning our self-guided training course, and
incorporating it into the documentation for the distribution. Our
course materials have been out of date for quite a while, and also
needed considerable reorganization. The new tutorial should be
simpler, clearer, better illustrated, and far easier to follow, and no
longer relies on any software outside the Galaxy Communicator
distribution. As for other changes in the distribution, the upgrade
should be completely transparent to just about everybody; there are no
publicly visible API changes, and so far, to my knowledge, there is
only one bug fix which could even possible affect observed
behavior. Our target date for the final release of GalaxyCommunicator
3.2 is November 1.

Galaxy Communicator 3.3/Open Source Toolkit v. 1
------------------------------------------------

Immediately after that, we'll be turning our attention to the assembly
of the first open source toolkit based on the Galaxy Communicator
infrastructure. This distribution will tie together a number of
wrappers we've been developing in-house, as well as well-tested
wrappers from sites like the University of Colorado and CMU. Our
ultimate goal is to provide, in a single package, a full array of
open-source servers and server wrappers to allow the construction of
free, real, fully capable Communicator-compliant systems. Some of the
wrappers will be for closed-source systems; but all of the code in the
open source toolkit will be fully open source. As part of this
release, we'll be removing some of the servers and wrappers from the
Galaxy Communicator distribution itself and moving them into the open
source toolkit distribution. This slightly reduced distribution of
Galaxy Communicator will be version 3.3. We intend to set up the open
source toolkit so that it can be updated frequently and easily; we
want to be able to capture the emerging state of the art as it
happens.

Galaxy Communicator 4.0
-----------------------

Our priorities for the 4.0 release are threefold:

- first, to support as robustly as possible the demands made by
  multimodal applications of the Galaxy Communicator infrastructure
- second, to support as robustly as possible the requirements of the
  AMITIES program, if it chooses to use the Galaxy Communicator
  infrastructure 
- third, to tie up loose ends appropriately so that the infrastructure
  is as cleanly and consistently implemented and documented as
  possible, given that the program is scheduled to end at the end of
  this coming fiscal year

Accordingly, here are the highest priority issues we're planning to
address: 

- MITRE has developed a prototype visualization server for the Hub,
  the hooks for which are disabled in the 3.1 distribution. In order
  to complete this server, we need to encapsulate and standardize the
  printouts and notifications in the Hub. In the process of doing
  this, we will probably also rationalize the print levels (verbosity)
  and document which levels do what.

- In order to support synchronization of multimodal input, we'll add
  timestamps to appropriate portions of the message traffic.

- We have a strong intuition that it would be valuable to provide
  support for tracking sequences of dependent tokens in the Hub. A
  token sent to synthesizer might cause a new token sent to audio
  output, for instance, and when it comes time to start backtracking
  from audio interruptions to compute how much information was
  conveyed to the user, robust support for these sorts of dependencies
  might turn out to be useful. We suspect that there are several
  problems that this sort of support could address.

- All examples, demos, and the tutorial ought to be able to run on
  Windows.

- We've added hooks for better broker encapsulation into the transport
  layer in 3.0. This support involves a dedicated broker datatype,
  which would be robustly identifiable by software such as HTTP
  firewall bridges which needs to be able to identify broker requests
  automatically. We'd like to finish adding this functionality.

Other things which might be on the list, time permitting:

- Finish the transition to GNU configure, so it's easier to maintain
  and add Communicator ports.

- Support for remote logging, and a reference implementation of a
  logging server which generates XML directly.

- Figure out a better, more consistent approach to managing listener
  locations. 

One thing which we're beginning to think we're not going to have time
for is providing an alternative Hub scripting facility based on a
real scripting language such as Python. Getting this right would be
fairly time-consuming, and we're not convinced it's a good investment
of our time right now. 

What do you think of these priorities? Do you think some of them
should be higher, or lower? Do you think some of them shouldn't be
there at all? What have we missed? What would YOU like to see in the
next major release (or even the next minor release, if it's simple
enough)? Some of these elements, like timestamps for multimodal
support, might be something we should provide before the 4.0
release. Please let us know if you feel that way.

If you'd like to provide feedback, please do so by November 1. We'll
gladly accept input after that date, but we can't guarantee that it
will be in time to guide our plans. You can send feedback directly to
me, or to bug...@mi..., whichever you prefer.

Thanks for reading -
Sam Bayer
for the Communicator team