[Communicator-user] SECOND CALL: Galaxy Communicator 4.0 survey

[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 -

Now that Galaxy Communicator 3.2 has been released we've
started work on the Open Source Toolkit, and now that the 2001 DARPA
Communicator evaluation is finished, I'd like to remind you all of our
default priorities for Galaxy Communicator 4.0 and solicit once again
any recommendations for changes, deletions or additions. I've pushed
back my requested date for response to December 15.

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 December 15. 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