|
From: Samuel L. B. <sa...@mi...> - 2001-11-15 19:51:57
|
[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 |