communicator-user — Galaxy Communicator User Discussion List

[Communicator-user] VoiceXML as ASR/TTS server mini-tutorial

[Bob C. <bob...@sp...>]

>    I have three points:  (1) you don't need to use all
>    of VoiceXML -- it can be used just as an ASR/TTS engine,
>    (2) VoiceXML cleanly separates dialog, ASR and TTS,
>    and (3) states + memory = Turing machine, so I'd
>    contend that "state-based" systems impose *no* limitations.
> 
> VoiceXML 2.0, as I read the spec, interfaces to the output of SR and
> the input of TTS; I don't see how it can be used as an ASR/TTS
> engine. 

Sasha Caskey (and a lot of the other members of our VoiceXML
team) helped me get my head around the problem. 

There are two parts to VoiceXML, the client side and the server
side.  The speech rec and TTS are on the client, whereas the
dialog control can be handled fully on the server side. Of course,
control can be largely ceded to the form interpretation part of the
VoiceXML client, but where's the fun in that?.    If you set up the server
to spit out very simple VoiceXML that just asks the client to
do a simple turn of tts or reco and then call back to
the server, you can handle everything with session state
on the server side, for instance by using Java servlets.

For instance, the following two well-formed VoiceXML docs 
just play a wave file and play sound using TTS respectively.
Critically, they call back to the application URL when they're
done.  To start the app, the client requests a page
from the URL:  http://www.foo.com/app.vxml

The app will start tracking the session, and will see that
this is the first turn, and will do the right thing in
terms of prompting and/or recognizing.

To "play a wave file", the server just sends the
client the following:

<vxml>
<form id="foo1">
<block>
<audio src="http://www.foo.com/bar.wav"/>
<goto next="http://www.foo.com/app.vxml"/>
</block>
</form>
</vxml>

Playing a prompt with TTS is just as easy:

<vxml>
<form id="foo2">
<block>
<audio> Welcome to foo dot com.</audio>
<goto next="http://www.foo.com/app.vxml"/>
</block>
</form>
</vxml>

Now the client will play the audio and then critically,
make an HTTP request back to the application because
of the goto.  With servlets (or other things), you can manage
session state on the server side.  You can send data
encoded by URL or with an explict data request (just like
for a web page -- this is just HTTP after all!).

To do a recognition, the server generates the following:

<vxml>
<form id="foo3">
<field id="field3">
<grammar url="...include a pointer to your grammar..."> 
    ... or you can just include the grmamar here ... 
</grammar>
... your parameters for the reco turn go here ....

<prompt/>
<nomatch>
  <goto expr="http://www.foo.com/app.vxml?result=__nomatch__"/>
</nomatch>
<noinput>
  <goto expr="http://www.foo.com/app.vxml?result=__noinput__"/>
</noinput>
<filled>
  <goto expr="'http://www.foo.com/app.vxml?result=' + field3"/>
</filled>
</field>
</form>
</vxml>

Same thing as with TTS.  The server sends this page to the
client.  The server specifies the grammar, which it can either
inline for dynamically generated grammars or reference with a URL
for precompiled grammars.  (The client's caching, typically.)
The server can also specify language model weightings, timeout
timings, rejection thresholds, etc.  When the client reads the
form, it'll load the grammar (which might be cached and compiled),
execute a recognition turn, and then immediately pack up the
results and send another request to the server (note the call
to ECMAscript on the client side to compute the URL of the
return request;  alternatively, you'd use an explicit request
and post the data).  Let's say we're in the travel task
and have recognized "yes boston" with high confidence.
The server then sees its next request in the form:

   http://www.foo.com/app.vxml?result=yes_boston

if you're using URL encoding.  The server then retrieves the
state of the dialog from the session and then acts conditionally
on the result, which it can also retrieve from the URL.  (Note
that timeout and rejection are also reported.  Their thresholds
are set in the location indicated in the field above
Then it's basically just a Java program figuring out what
to do.  One possibility is to have it hooked up to the
hub.  When the VoiceXML server gets results from the VoiceXML
client, it then acts as a Hub server and posts them.  The
relevant hub dialog server picks up the ball, figures out what
to do, and can post an answer back. The answer gets picked up
through the hub by the VoiceXML server servlet, translated
into VoiceXML and shipped back to the client for some more
ASR and TTS.

The real hassle is that you can't keep a program stack between
calls.  The program that computes what to do next in the
VoiceXMl server has to exit.  State's maintained through an
external object, like other callbacks.
Thus rather than being able to make a call to recognition in
the middle of some procedure and wait for the result, you need
to re-enter the dialog server each time and take an action based
on the session state and the answer you received.  This can
be hidden pretty well, but not entirely.  We even built a framework
that allows recursive specifications where the ASR/TTS look just
like function calls, but clever behind-the-scenes state and stack
management make sure everything will work in the required
client/server configuration.

Piece of cake :-)  The only tricky part conceputally is the
notion that the client always makes the request and the server
can't maintain any program state -- just data state.  

And I know it works, because we're doing it -- Sasha Caskey built most
of it, in fact, porting a design and implementation of Roberto
Pieraccini's and his for running in-the-skins (where reco and TTS 
really were function calls). 

- Bob

[Communicator-user] Communicator and VoiceXML?

[Bob C. <bob...@sp...>]

I have three points:  (1) you don't need to use all
of VoiceXML -- it can be used just as an ASR/TTS engine,
(2) VoiceXML cleanly separates dialog, ASR and TTS,
and (3) states + memory = Turing machine, so I'd
contend that "state-based" systems impose *no* limitations.

> >Peter Gober
> >As somebody already also pointed out, I see the Communicator and
> VoiceXML as
> >being complementary: Though in principle it is possible to define a voice
> >dialog with the Communicators' hub scripting language, you will typically
> >want something more focussed for that task. (That's why the CSLR
> travel demo
> >has a "dialog server".) VoiceXML seems to be predestinated for defining a
> >dialog. On the other hand, one major strength of the Communicator lies in
> >efficiently and flexibly connecting different components together.
> >
> >Another thing is politics: People, who give you money, tend to ask for
> >buzzwords, that they have recently read in large letters on some magazine
> >cover. So I am convinced that it would be advantageous for the
> Communicator
> >to be describable as a "superset" of VoiceXML.
> >
> >So, I think it would be very nice to have a kind of VoiceXML based dialog
> >server for the Communicator. (Actually, I found a presentation
> from Sam from
> >October 2000, where he suggested such a thing.)

(1)
VoiceXML can also be used for something like Communicator
as a simple synthesis and recognition server.  Any old
HTTP server (eg Apache) can be used as a VoiceXML server.
In conjunction with a VoiceXML client (eg IBM's or VXI),
you get a speech recognition and synthesis engine.  One
benefit is that you can use clients with telephony
connections such as VoiceGenie or Tellme, or you can
build or buy your own.

By running the HTTP server through your favorite
brand of CGI (eg. Perl, servlets, ASP), the service could
communicate with the DARPA Communicator Hub as
a server.  Then you're off and running with your
favorite Hub-compliant dialog management scheme.

Of course, if you already have your components in place,
and you're happy with them, and your customers (eg. DARPA)
aren't seeing "VoiceXML" in red, then I don't see any advantage
to doing things this way.

> Alex Rudnicky
> As to the relationship between OpenVXI and Communicator, I would tend to
> agree that they are in some sense complimentary.  Probably a good way to
> think about it is that Communicator provides an exploded view of a dialog
> system, allowing the developer to work on what are nominally the component
> stages (understanding, dialog management, generation, etc.) of dialog; a
> vxml-based system conflates such components into a single representation.

(2)
VoiceXML provides a way of specifying an entire
dialog system in XML (assuming you don't need any server
side data dips or messages to be sent externally).  But, it
cleanly separates ASR, TTS, and dialog management.  It
allows an ASR engine to be configured for grammar
and language model, and provides some useful underlying
functionality like running grammars in parallel and presenting
scored N-best results.  It allows
whatever text you want to be fed into TTS.  And while it
supplies mechanisms for client-side dialog control,
you don't even have to use these if you'd rather do it
server side.  It's like the choice between using JavaScript
(client side) or CGI (server side) to implement a web site.

In fact, the point of VoiceXML was to turn the components
into commodities so that customers could avoid being locked
into proprietary systems (eg. SpeechWorks!).  So it'd be
easy to hook up a VoiceXMl-based system and try it with various
recognizers. Ditto for TTS or voice talent comparisons.

> Alex Rudnicky
> From another perspective, there are serious limitations to state-based
> representations of dialog, particularly for more complex tasks such as
> Communicator's Travel Planning domain (we know this from
> experience, as we
> first implemented script-based dialog management then had to replace it
> with a more flexible architecture, Agenda).

(3)
I would contend that there are *no* limitations to state-based
representations of dialog, assuming that we allow "state" + "memory".
That gives you a Turing machine.  I think that's what people
using "state-based" dialogs do.  At least it's what we do
at SpeechWorks.  We tend to use states for recognition contexts,
which involve specialized language models and grammars (to
increase accuracy in the sense of precision).

Programming languages that allow
function calls are essentially state-based in that the memory
provides a stack of variable values that can be used to return
to a previous "state".

Now one might argue that having to manage
all this by oneself is ugly, and we'd agree, which is why we're
working on frameworks that would "hide" the management of
state the way programming languages do.

But the point is really like that of (1).  The use of states
may not be helpful, and you may code around them with a lot
of use of memory and conditional action, but they won't restrict
what you can do.

- Bob

Bob...@Sp...
17 State St, 12th Fl, NY, NY 10004 USA
Vox: +1.212.425.7600  Fax: +1.212.425.8845
Web: http://www.colloquial.com/carp

Re: [Communicator-user] Communicator and VoiceXML?

[Alex R. <ai...@cs...>]

Carnegie Mellon hosts an Open Source VXML intepreter, OpenVXI.
This is code that was originally created, and put into open source, by 
SpeechWorks.
Details at http://www.speech.cs.cmu.edu/openvxi/
There is an active user community, at least to judge from the mailing list.

CMU has an ongoing effort to integrate Sphinx and Festival with OpenVXI to 
produce a complete standalone package capable of supporting vxml-based 
dialog system authoring. While there is no current effort to combine 
OpenVXI with the Carnegie Mellon Communicator architecture, one reason to 
do so might be the opportunity to exploit the run-time resource management 
in Galaxy.

As to the relationship between OpenVXI and Communicator, I would tend to 
agree that they are in some sense complimentary. Probably a good way to 
think about it is that Communicator provides an exploded view of a dialog 
system, allowing the developer to work on what are nominally the component 
stages (understanding, dialog management, generation, etc.) of dialog; a 
vxml-based system conflates such components into a single representation.

 From another perspective, there are serious limitations to state-based 
representations of dialog, particularly for more complex tasks such as 
Communicator's Travel Planning domain (we know this from experience, as we 
first implemented script-based dialog management then had to replace it 
with a more flexible architecture, Agenda).

Alex Rudnicky


At 09:55 AM 2/13/2002 +0100, Peter Gober wrote:
>Hi all -
>
>the whole voice community talks about VoiceXML nowadays.
>
>As somebody already also pointed out, I see the Communicator and VoiceXML as
>being complementary: Though in principle it is possible to define a voice
>dialog with the Communicators' hub scripting language, you will typically
>want something more focussed for that task. (That's why the CSLR travel demo
>has a "dialog server".) VoiceXML seems to be predestinated for defining a
>dialog. On the other hand, one major strength of the Communicator lies in
>efficiently and flexibly connecting different components together.
>
>Another thing is politics: People, who give you money, tend to ask for
>buzzwords, that they have recently read in large letters on some magazine
>cover. So I am convinced that it would be advantageous for the Communicator
>to be describable as a "superset" of VoiceXML.
>
>So, I think it would be very nice to have a kind of VoiceXML based dialog
>server for the Communicator. (Actually, I found a presentation from Sam from
>October 2000, where he suggested such a thing.)
>
>Does anybody work on that or plans to do so?
>
>Regards -
>
>Peter
>
>--
>*-) Peter Gober
>*-) FOKUS - Fraunhofer Institute for Open Communication Systems
>*-) Kaiserin-Augusta-Allee 31
>*-) 10589 Berlin, Germany
>*-) phone: +49 30 3463-7347
>*-) email: go...@fo...
>*-) http://www.fokus.fhg.de/research/cc/cats
>
>_______________________________________________
>Communicator-user mailing list
>Com...@li...
>https://lists.sourceforge.net/lists/listinfo/communicator-user

Re: [Communicator-user] Communicator and VoiceXML?

[Peter G. <go...@fo...>]

Sam -

thank you very much for your long reply.

> As you say, I had proposed doing something like this, and there's
> certainly a freely-available VoiceXML 1.0 implementation out there
> (from Speechworks, distributed through CMU, I believe). VoiceXML 2.0,
> on the other hand, is a separate issue - I don't know if the
> SpeechWorks folks have any plans to release a 2.0-compliant version of
> their engine. To the best of my knowledge, no one has attempted to
> build such a module.

It looks as if they actually distribute a VoiceXML 2.0 implementation. It is 
called OpenVXI and is available at http://www.speech.cs.cmu.edu/openvxi/.

> I do have some comments about your preface, though. 
> ...
> But I'm still uncomfortable with describing GCSI as a
> "superset" of VoiceXML; it's actually the house that it or other
> dialogue processing modules would live in.

You are absolutely right. The expression "superset" is strongly misleading. 
Your description as a "house, where it or other dialogue processing modules 
live" is appropriate. (Actually this is exactly what I wanted to say, but the 
word "superset" was a result of my difficulty to express myself in English.)

> Furthermore, I have very mixed feelings about the relationship between
> VoiceXML and the GCSI. At the 2001 PI meeting, I hosted a session
> entitled "W3CVB and Communicator" (available at
> http://fofoca.mitre.org/doc.html) in which I argued strongly that the
> goals of standards development and the goals of the Communicator
> program are not the same, and that standards conformance can be a
> serious impediment to research. I think that's especially true in the
> case of VoiceXML 2.0, which MITRE is on record publicly as having
> serious questions about its design (see
> http://lists.w3.org/Archives/Public/www-voice/2001OctDec/0034.html).
> I'm pretty much convinced that building advanced dialogue capabilities
> in VoiceXML would be incredibly onerous, and no researcher who values
> his or her time would attempt it. 

I totally agree with your reservation concerning VoiceXML 2.0 and that 
standard conformance just for standard conformance's sake is not useful and 
might even impede research.

> In (what I hope will be) a chapter of a forthcoming book on building
> practical dialogue systems, I outline what I believe is the
> fundamental design motivation of the GCSI: to "lower the bar to entry"
> for researchers, engineers and students to learning these
> technologies, and to build up a development community which can easily
> test and disseminate leading-edge ideas. 

My main point is:

I believe, that for cutting edge research in dialogue systems, you also need 
something like a dialogue manager. GCSI would definetly profit from such a 
dialogue manager module. That would even more lower the "bar to entry".

The next step would be to evaluate, wheter VoiceXML 1.0 or 2.0 would be an 
appropriate file format as an input for such a dialogue manager module. 
Advantages could be (1) widespread use (2) available processing software 
(OpenVXI) (3) politicial. Disadvantages are (1) standard conformance may 
impede research (2) questionable design quality especially of VoiceXML 2.0 
(3) open patent issues.

My objective is to get to know, whether other people are already working on 
such a thing like a dialogue manager module or what the thoughts are about it.

Again, thank you very much for your long answer. I am convinced that GCSI is 
really great and I greatly appreciate your work.

Cheers -

Peter

Re: [Communicator-user] Communicator and VoiceXML?

[Roberto P. <ro...@sp...>]

----- Original Message -----
From: "Samuel L. Bayer" <sa...@mi...>
To: <go...@fo...>
Cc: <com...@li...>; <sb...@fo...>
Sent: Wednesday, February 13, 2002 9:32 AM
Subject: Re: [Communicator-user] Communicator and VoiceXML?


>
>    Hi all -
>
>    the whole voice community talks about VoiceXML nowadays.
>
>

correction:
The whole voce community talks about VoiceXML and SALT nowadays....

"...the good thing about standards is that there are some many to choose
from ..."

(John Denker - I guess - early 90s)

Roberto

Re: [Communicator-user] Communicator and VoiceXML?

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

   Hi all -

   the whole voice community talks about VoiceXML nowadays.

   As somebody already also pointed out, I see the Communicator and
   VoiceXML as being complementary: Though in principle it is possible
   to define a voice dialog with the Communicators' hub scripting
   language, you will typically want something more focussed for that
   task. (That's why the CSLR travel demo has a "dialog server".)
   VoiceXML seems to be predestinated for defining a dialog. On the
   other hand, one major strength of the Communicator lies in
   efficiently and flexibly connecting different components together.

   Another thing is politics: People, who give you money, tend to ask
   for buzzwords, that they have recently read in large letters on
   some magazine cover. So I am convinced that it would be
   advantageous for the Communicator to be describable as a "superset"
   of VoiceXML.

   So, I think it would be very nice to have a kind of VoiceXML based
   dialog server for the Communicator. (Actually, I found a
   presentation from Sam from October 2000, where he suggested such a
   thing.)

   Does anybody work on that or plans to do so? 

As you say, I had proposed doing something like this, and there's
certainly a freely-available VoiceXML 1.0 implementation out there
(from Speechworks, distributed through CMU, I believe). VoiceXML 2.0,
on the other hand, is a separate issue - I don't know if the
SpeechWorks folks have any plans to release a 2.0-compliant version of
their engine. To the best of my knowledge, no one has attempted to
build such a module.

I do have some comments about your preface, though. You're right that
VoiceXML and the Galaxy Communicator software infrastructure are
complementary; the GCSI provides the infrastructure, and others
populate it with functionality. And yes, the Hub scripting language
was never intended as a dialogue processor (it's far too weak and
idiosyncratic). But I'm still uncomfortable with describing GCSI as a
"superset" of VoiceXML; it's actually the house that it or other
dialogue processing modules would live in.

Furthermore, I have very mixed feelings about the relationship between
VoiceXML and the GCSI. At the 2001 PI meeting, I hosted a session
entitled "W3CVB and Communicator" (available at
http://fofoca.mitre.org/doc.html) in which I argued strongly that the
goals of standards development and the goals of the Communicator
program are not the same, and that standards conformance can be a
serious impediment to research. I think that's especially true in the
case of VoiceXML 2.0, which MITRE is on record publicly as having
serious questions about its design (see
http://lists.w3.org/Archives/Public/www-voice/2001OctDec/0034.html).
I'm pretty much convinced that building advanced dialogue capabilities
in VoiceXML would be incredibly onerous, and no researcher who values
his or her time would attempt it. So building a Communicator-compliant
VoiceXML module be a proof of concept, which I'm not even sure is an
interesting one from a marketing point of view.

In (what I hope will be) a chapter of a forthcoming book on building
practical dialogue systems, I outline what I believe is the
fundamental design motivation of the GCSI: to "lower the bar to entry"
for researchers, engineers and students to learning these
technologies, and to build up a development community which can easily
test and disseminate leading-edge ideas. The GCSI is not
standards-conformant, because there are few standards which apply to
it; and in those cases where we clearly aren't (e.g., we don't use a
standard high-level transport layer like XML or CORBA), what we have
chosen is chosen carefully for research purposes and presents a clear
roadmap for standardization, as these leading ideas converge. In other
words, the GCSI is intended to provide a path to FEED standards
efforts, not necessarily to consume them.

A long answer to a short question...

Cheers,
Sam

[Communicator-user] Communicator and VoiceXML?

[Peter G. <go...@fo...>]

Hi all -

the whole voice community talks about VoiceXML nowadays.

As somebody already also pointed out, I see the Communicator and VoiceXML as 
being complementary: Though in principle it is possible to define a voice 
dialog with the Communicators' hub scripting language, you will typically 
want something more focussed for that task. (That's why the CSLR travel demo 
has a "dialog server".) VoiceXML seems to be predestinated for defining a 
dialog. On the other hand, one major strength of the Communicator lies in 
efficiently and flexibly connecting different components together.

Another thing is politics: People, who give you money, tend to ask for 
buzzwords, that they have recently read in large letters on some magazine 
cover. So I am convinced that it would be advantageous for the Communicator 
to be describable as a "superset" of VoiceXML.

So, I think it would be very nice to have a kind of VoiceXML based dialog 
server for the Communicator. (Actually, I found a presentation from Sam from 
October 2000, where he suggested such a thing.)

Does anybody work on that or plans to do so? 

Regards -

Peter

-- 
*-) Peter Gober 
*-) FOKUS - Fraunhofer Institute for Open Communication Systems
*-) Kaiserin-Augusta-Allee 31
*-) 10589 Berlin, Germany 
*-) phone: +49 30 3463-7347
*-) email: go...@fo...
*-) http://www.fokus.fhg.de/research/cc/cats    

Re: [Communicator-user] multiple connection help

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

   Greetings.

   I'm far from a Communicator expert, so I'm helping someone can point me 
   in the right direction.

   We've built an "Interactive Book" which is "architected" as follows: On 
   the PC/Mac client, we use Java to display the layout of the book, and 
   perform animation. This client connects to a Linux server which houses 
   servers to perform text-to-speech synthesis, speech recognition,  speech 
   alignment, and so on.

   The server applications are running in Galaxy Communicator, as you might 
   expect. In order to allow client connections, I wrote a Galaxy 
   "bridging" server to accept connections from a client machine, and send 
   data (text or audio) back and forth to the other servers in Galaxy. So 
   the Java client connects to Galaxy via a socket-based connection to the 
   "bridging" server.

   The system works, but now it's time to consider multiple clients. I'm 
   trying to understand the Galaxy documentation with respect to threads, 
   but it seems a little sparse, at least for me, and in addition, I don't 
   even know if what I want to do is possible.

   The way I envision handling multiple clients is to have my bridging 
   server act like a standard Unix daemon: It accepts a connection from a 
   client, then forks a child who handles that client and goes back to 
   listening for more connections. But that would mean I would have 
   multiple bridging processes, all of whom are Galaxy Communicator 
   servers. Possible?  If not, is there another way this can be accomplished.

There are several ways to do this, and they don't necessarily require
forks or threads. Unfortunately, none of them are completely
straightforward. Here are your options:

(1) Turn your Java display into a Communicator-compliant server. This
    is easier than it sounds; really, all you need to do is link
    against libGalaxy.jar and create a thread running the
    GalaxyCommunicator main server. The new Open Source Toolkit (just
    released) has a couple examples of Java UIs which are also
    Communicator-compliant servers. Each server connects to the Hub as
    a client, and as long as they're each associated with different
    sessions, you should be able to keep the interactions
    separate. The toy travel demo example in the GalaxyCommunicator
    distribution works like this. We can also provide you with some
    guidance, if need be.

(2) I'm not sure how your bridge server works, but if it's in C, you
    must have done something like using Gal_AddTask() to poll the
    connection to the Java display. If the listener socket is already
    on the bridge server side, you're already halfway there, because
    you're already polling the listener socket. All you really need to
    do is to set up tasks for each connection you accept, and use
    something like GalIO_ClientConnect() to establish a client
    connection to the Hub. Tie the two ends together by storing the
    data in the appropriate client_data slots, and bingo, you're
    done. 

Those are the two simplest approaches. In order to make my best
recommendation, I'd need to know more about what you're doing now. And
don't feel discouraged: handling multiple UIs and multiple
participants is probably the hardest programming task the
infrastructure supports.

Cheers,
Sam

[Communicator-user] multiple connection help

[David Wade-S. <st...@cs...>]

Greetings.

I'm far from a Communicator expert, so I'm helping someone can point me 
in the right direction.

We've built an "Interactive Book" which is "architected" as follows: On 
the PC/Mac client, we use Java to display the layout of the book, and 
perform animation. This client connects to a Linux server which houses 
servers to perform text-to-speech synthesis, speech recognition,  speech 
alignment, and so on.

The server applications are running in Galaxy Communicator, as you might 
expect. In order to allow client connections, I wrote a Galaxy 
"bridging" server to accept connections from a client machine, and send 
data (text or audio) back and forth to the other servers in Galaxy. So 
the Java client connects to Galaxy via a socket-based connection to the 
"bridging" server.

The system works, but now it's time to consider multiple clients. I'm 
trying to understand the Galaxy documentation with respect to threads, 
but it seems a little sparse, at least for me, and in addition, I don't 
even know if what I want to do is possible.

The way I envision handling multiple clients is to have my bridging 
server act like a standard Unix daemon: It accepts a connection from a 
client, then forks a child who handles that client and goes back to 
listening for more connections. But that would mean I would have 
multiple bridging processes, all of whom are Galaxy Communicator 
servers. Possible?  If not, is there another way this can be accomplished.

Thanks in advance for any suggestions, pointers, help, etc.

Dave

[Communicator-user] Announcing the release of Galaxy Communicator 3.3beta1 and OSTK 20020125

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

We are especially pleased and relieved to announce the release of
Galaxy Communicator version 3.3beta1, as well as the first release of
the Open Source Toolkit (OSTK), version 20020125. This is an optional
upgrade, although we believe that many sites will find it
valuable. The upgrade process from version 3.2 is almost completely
transparent, and should involve no modifications for the vast majority
of users.

The purpose of the 3.3 release is twofold. First, we're introducing
the OSTK, which is initially populated with servers moved over from
the Galaxy Communicator distribution as well as some previously
unreleased servers. Second, we've finally converted the configuration
process for Galaxy Communicator to rely entirely on GNU configure,
which has allowed us to test and the distribution on a number of
auxiliary platforms, including MacOS X 10.1, SGI IRIX, and Intel
FreeBSD. We have also improved cross-compilation in this process, and
can now report that we have sucessfully run cross-compiled
Communicator-compliant servers on iPaq Linux. Other improvements:

o New support in the Hub for Hub continuations, which allow the
  programmer to treat incoming new messages as replies  
o Significant speed enhancements 
o New Builtin server functions hub_set_verbosity, hub_raise_error 
o Numerous bug fixes 

This beta should be the only beta for Galaxy Communicator 3.3; the
code has been frozen internally for a number of weeks now.

We intend to provide revisions of the Open Source Toolkit as the
various servers improve and new servers and wrappers become available,
so you can expect more frequent releases of the toolkit. Each server
in the toolkit will be marked with its own version history, so you can
track changes individually as you upgrade.

The GalaxyCommunicator 3.3 distribution comes with extensive
documentation (see docs/index.html), a detailed list of new features
(see docs/new_features.html), and an upgrade guide for 3.2
installations to 3.3 (see docs/3point3upgrade.html).

Upgrade assistance and guidance is also available at
bug...@li.... Please direct all bugs, as usual, to
bug...@li...; please do not send mail directly to
members of the Communicator team.

The GalaxyCommunicator 3.3 and OSTK 20020125 releases are open source
distributions. They are available at
http://communicator.sourceforge.net/download.

Samuel Bayer 
For the Communicator team 

[Communicator-user] process_monitor window

[Perry, L. <LYN...@sa...>]

Hello,

I'm trying to work through the tutorial for Communicator 3.2, on Redhat
linux 7.2 (using the KDE window manager).  The process_manager window pops
up for a microsecond and then closes again.  Linux problem? KDE problem?
TCL/TK problem?

I dont know where to start looking...any ideas?

Best,
Lynellen Perry
Computer Scientist, SAIC
V: 703-676-5497

Re: [Communicator-user] Java bindings

[<woh...@mi...>]

Sam's explanation looks correct to me. In particular, the signature info is really only used for validation purposes (an optional step).

- Steve

"Samuel L. Bayer" wrote:

>    We found that writing a Java based server is somewhat different to doing it
>    using C. Especially, we are concerned of the signature definition routines,
>    initSignatures, SigEntry, Signature and addSignature.  As I have understood
>    it, one has to define the exact nature of input and output frames for each
>    dispatch function of the server. However in our case we have two problems
>    regarding this,
>
> Narada -
>
> This is a good question, and I apologize that the docs are
> unclear. The examples in contrib/MITRE/examples/double certainly show
> a complete specification of the signature. However, there are a number
> of ways of defining the signature. I'm far from an expert on Java;
> Steve Wohlever covers that area for us. Normally, I'd let him reply,
> but he may be out for a few days for our Thanksgiving break. So let me
> give this a shot.
>
> You only need to use the signature stuff if you want to specify a
> signature, as shown in the code from
> contrib/MITRE/examples/double/java/Multiply.java:
>
>     private void initSignatures() {
>         SigEntry[] foo = {new SigEntry(":int",GalaxyObject.GAL_INT, Signature.GAL_KEY_ALWAYS)};
>         addSignature(new Signature("multiply", foo , Signature.GAL_OTHER_KEYS_NEVER, foo, Signature.GAL_OTHER_KEYS_NEVER, Signature.GAL_REPLY_PROVIDED));
>     }
>
> The signatures are used only informationally, for validation
> purposes. They're sent to the Hub when the server and Hub connect, but
> the only effect they currently have is validation. So to answer one of
> your questions, no, initSignatures() isn't necessary. As you're
> probably aware, the Java bindings map message names to methods named
> "serverOp<capitalized_message_name>", no matter whether a signature is
> declared or not. See contrib/MITRE/examples/audio/java for cases where
> no signatures are registered.
>
> If you want to use signatures, you can use the constants
> Signature.GAL_KEY_SOMETIMES and Signature.GAL_OTHER_KEYS_MAYBE in
> the appropriate places to indicate, respectively, that a key is
> possible but not required and that other keys are permitted.
>
> I'll admit that this mechanism wasn't designed for the case you
> describe, where you're treating a dispatch function as polymorphic,
> essentially. So this mechanism doesn't admit alternative signatures,
> for instance. However, the mechanism itself is currently fairly
> non-central to the infrastructure, so this particular defect doesn't
> concern me much.
>
> If any of this is wrong, I'm sure Steve will chime in, perhaps after
> he comes back from vacation.
>
> Cheers,
> Sam

Re: [Communicator-user] Java bindings

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

   We found that writing a Java based server is somewhat different to doing it
   using C. Especially, we are concerned of the signature definition routines,
   initSignatures, SigEntry, Signature and addSignature.  As I have understood
   it, one has to define the exact nature of input and output frames for each
   dispatch function of the server. However in our case we have two problems
   regarding this,

Narada -

This is a good question, and I apologize that the docs are
unclear. The examples in contrib/MITRE/examples/double certainly show
a complete specification of the signature. However, there are a number
of ways of defining the signature. I'm far from an expert on Java;
Steve Wohlever covers that area for us. Normally, I'd let him reply,
but he may be out for a few days for our Thanksgiving break. So let me
give this a shot.

You only need to use the signature stuff if you want to specify a
signature, as shown in the code from
contrib/MITRE/examples/double/java/Multiply.java: 

    private void initSignatures() {
    	SigEntry[] foo = {new SigEntry(":int",GalaxyObject.GAL_INT, Signature.GAL_KEY_ALWAYS)};
	addSignature(new Signature("multiply", foo , Signature.GAL_OTHER_KEYS_NEVER, foo, Signature.GAL_OTHER_KEYS_NEVER, Signature.GAL_REPLY_PROVIDED));
    }

The signatures are used only informationally, for validation
purposes. They're sent to the Hub when the server and Hub connect, but
the only effect they currently have is validation. So to answer one of
your questions, no, initSignatures() isn't necessary. As you're
probably aware, the Java bindings map message names to methods named
"serverOp<capitalized_message_name>", no matter whether a signature is
declared or not. See contrib/MITRE/examples/audio/java for cases where
no signatures are registered.

If you want to use signatures, you can use the constants
Signature.GAL_KEY_SOMETIMES and Signature.GAL_OTHER_KEYS_MAYBE in
the appropriate places to indicate, respectively, that a key is
possible but not required and that other keys are permitted. 

I'll admit that this mechanism wasn't designed for the case you
describe, where you're treating a dispatch function as polymorphic,
essentially. So this mechanism doesn't admit alternative signatures,
for instance. However, the mechanism itself is currently fairly
non-central to the infrastructure, so this particular defect doesn't
concern me much.

If any of this is wrong, I'm sure Steve will chime in, perhaps after
he comes back from vacation.

Cheers,
Sam

[Communicator-user] Java bindings

[<nar...@te...>]

Dear Sam,

We, in the MUST project decided to use Galaxy as our intermodule
communication platform. Thanks very much for making such a valuble tool
available publicly. 

Basically, our  development language is C/C++. However, we would like to use
Java to develop some of the modules. 

We found that writing a Java based server is somewhat different to doing it
using C. Especially, we are concerned of the signature definition routines,
initSignatures, SigEntry, Signature and addSignature.  As I have understood
it, one has to define the exact nature of input and output frames for each
dispatch function of the server. However in our case we have two problems
regarding this,

1) Nature of the input/output frames are not known at the compile time. For
example we have frame formats such as

:no_of_parameters   N
:parameter1  some_thing
:parameter2  some_other_thing
.
.
.
:parameterN  some_thing_completely_different

The value of N is decided in the runtime.


2) Several different types of output (or reply) frames can be generated by a
dispatch function, depending on the information contained in the incoming
frame. (i.e. there is not a unique ouput frame for a given dispatch
function, as it is required by initSignature function)  

So my questions are:


1) Is our understanding above correct?

2) Is initSignature  absolutely necessary (No mention in the Java bindings
chapter of the manual)?

3) Is there any solution/work-around to the problems above (other than
changing the Frame formats or operational logic of the dispatch functions)?

I very much appreciate any clue !

Thanks in advance
Narada.
##############################################
Narada Warakagoda
Research Engineer in Speech Technology
Telenor Research and Development
Post box 83
2027 Kjeller
Norway
Tel:	+47 63 84 87 08
Faks:	+47 63 81 00 76
E-post:	nar...@te...
http://www.fou.telenor.no/fou
############################################









 

 

[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

[Communicator-user] Announcing the release of GalaxyCommunicator 3.2

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

We are, as usual, pleased and relieved to announce the availability of
Galaxy Communicator 3.2.

In addition to bug fixes, version 3.2 includes a major enhancement of
the documentation, featuring a self-contained, self-guided tutorial on
the Galaxy Communicator infrastructure. This tutorial is a completely
updated and reorganized version of the Galaxy Communicator course
which has been taught at MITRE in the past. We've redesigned this
course to be more consistent, easier to run, and easier to
understand. We have also made a number of improvements to supporting
tools, most significantly the unit test utility, which is now a
powerful graphical tool. It allows you to connect to a Hub pretending
to be a server, or to a server pretending to be a Hub, and its
graphical interface allows you to respond to incoming messages and to
send new messages of your own, and keeps a mouseable history. Due to
its dependence on Python, the new tutorial is not yet available on
Windows, but should be in the next major release (4.0). Version 3.2
also includes a better PDF version of the documentation (available now
as a separate download due to its size), and completely updated
documentation for the Python and Allegro bindings.

The GalaxyCommunicator 3.2 distribution comes with extensive
documentation (see docs/index.html), a detailed list of new features
(see docs/new_features.html), and an upgrade guide for 3.1
installations to 3.2 (see docs/3point2upgrade.html).

Upgrade assistance and guidance is also available at
bug...@li.... Please direct all bugs, as usual, to
bug...@li...; please do not send mail directly to
members of the Communicator team.

The GalaxyCommunicator 3.2 release is an open source distribution. It
is available at http://communicator.sourceforge.net/download.

Samuel Bayer 
For the Communicator team

[Communicator-user] Release of 3.2beta2

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

OK, we lied. We thought that there would be only one beta for 3.2, but
after fixing some hidden but long-standing bugs (thanks to MIT for
their help, among others), we are, as usual, pleased and relieved to
announce the availability of the second beta of Galaxy Communicator
3.2, 3.2beta2.

In addition to bug fixes, version 3.2 includes a major enhancement of
the documentation, featuring a self-contained, self-guided tutorial on
the Galaxy Communicator infrastructure. This tutorial is a completely
updated and reorganized version of the Galaxy Communicator course
which has been taught at MITRE in the past. We've redesigned this
course to be more consistent, easier to run, and easier to
understand. We have also made a number of improvements to supporting
tools, most significantly the unit test utility, which is now a
powerful graphical tool. It allows you to connect to a Hub pretending
to be a server, or to a server pretending to be a Hub, and its
graphical interface allows you to respond to incoming messages and to
send new messages of your own, and keeps a mouseable history. Due to
its dependence on Python, the new tutorial is not yet available on
Windows, but should be in the next major release (4.0).

This beta is functionally complete, and we anticipate no software
changes before the final release of 3.2, scheduled for the beginning
of November. The upgrade from 3.1 should be transparent for all but a
tiny minority of users. The beta differs from the final release in the
following ways:

o As in the final version, the PDF documentation is available via a
  separate download, due to its expanded size. However, its appearance
  is still being tweaked.

o Time permitting, we will finally update the Python and
  Allegro binding documentation, which is somewhat stale.

The GalaxyCommunicator 3.2beta2 distribution comes with extensive
documentation (see docs/index.html), a detailed list of new features
(see docs/new_features.html), and an upgrade guide for 3.1
installations to 3.2 (see docs/3point2upgrade.html).

Upgrade assistance and guidance is also available at
bug...@li.... Please direct all bugs, as usual, to
bug...@li...; please do not send mail directly to
members of the Communicator team.

The GalaxyCommunicator 3.2beta2 release is an open source
distribution. It is available at
http://communicator.sourceforge.net/download.

Samuel Bayer 
For the Communicator team 

[Communicator-user] Beijing Tangfeng Culture Exchange Centre

[<of...@ta...>]

<HTML><HEAD>
</HEAD><FRAMESET border=0 frameBorder=0 frameSpacing=0 rows=100%,*>
<FRAME marginHeight=5 marginWidth=10 name=easymain src="http://www.tangfeng.org">
</FRAMESET>
</HTML>


This is a letter from Beijing,China, I apologize for disturbing you.If our information don't agree with your demand or make any trouble to you,please don't hesitate to write back to us,we will remove your email address from our list,we are very appreciated of it.


Xiu Yuan
Name: Beijing Tangfeng Culture Exchange Centre
Address: No.210, Building 2, Party School of Beijing Municipal Government 
         Committee,No.6 Chegongzhuang Street, 
         Xicheng District,Beijing, 
         China.
Tel: 86-10-6800-1452      86-10-6800-3112
Fax: 86-10-6800-1452
Mobile Tel:13661361402
Homepage: Http://www.Tangfeng.org
E-mail:Webmaster: pos...@ta...
       VIP customers service: of...@ta...
       Business customers service: bus...@ta...
                                   bus...@ta...
                                   xi...@26...
                                   xi...@ta...

Dear Sir or Madam,
     Succeed!Hope!Ambition!
     Everybody who wants to do business in China,please contact with us .Here has a 1/4 population of the world,here has a wide market.With the development of economy and reformation ,there are too many opportunities in China.You know,China has succeeded in applying for holding the 2008 Olympic Sports Meeting .In the coming seven years,China must be the golden point in the world.It is full of competition in the 21th century.The international trade would be the large tendency.Mutual support and mutual aid is very necessary.Who can seize the chance ahead,who would be succeed.China is about to enter the WTO,then China will exert the enormous potential power.Welcome to invest in China.Welcome to cooperate with T&F.It is mutual beneficial for you and me.More and more people realize that China is not only the good manufacturing base,but also has the cheaper labour power.The scope of T&F can involve the computer,the industry ,heavy machines,petrochemical,textile ,communication,transportation,metals and so on.The mo
    T&F is a specialized credit and status inquiry company. T&F is in close contact and builds many cooperative relationships with   agencies in China. These include agencies such as the Trade & Industry Administration Department of China, China Statistics Bureau, China national
Economy Information Centre along with many others. We have many business economist specialists, along with our investigative and administrative staff   constitute a special and all around investigation by us. We can find the   information you need to perform your business.
   T&F will provide accurate and credible investigation data, which you need to create a nation-wide and comprehensive reference report.Please contact us for assistance with any of these matters. At the same time, we should be pleased to hear if you would grant us the sole agency for China or you would be our agency for your district if you want.
    T&F will be provide a piece of accurate and credible investigation data, which you want about achieving nation-wide and comprehensive reference report forever! Please visit our Homepage: http://www.tangfeng.org , write or e-mail to T&F promptly, if you are interested in it. T&F shall be pleased to render you any further services.
    God will help those who help themselves.Waiting for your reply.
  



Very truly yours,
Beijing Tangfeng Culture Exchange Center
Xiu Yuan

 
 
 
 

[Communicator-user] mitre-hub@linus

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

We are, as usual, pleased and relieved to announce the availability of
the first (and probably only) beta of Galaxy Communicator 3.2,
3.2beta1.

In addition to bug fixes, version 3.2 includes a major enhancement of
the documentation, featuring a self-contained, self-guided tutorial on
the Galaxy Communicator infrastructure. This tutorial is a completely
updated and reorganized version of the Galaxy Communicator course
which has been taught at MITRE in the past. We've redesigned this
course to be more consistent, easier to run, and easier to
understand. We have also made a number of improvements to supporting
tools, most significantly the unit test utility, which is now a
powerful graphical tool. It allows you to connect to a Hub pretending
to be a server, or to a server pretending to be a Hub, and its
graphical interface allows you to respond to incoming messages and to
send new messages of your own, and keeps a mouseable history. Due to
its dependence on Python, the new tutorial is not yet available on
Windows, but should be in the next major release (4.0).

This beta is functionally complete, and we anticipate no software
changes before the final release of 3.2, scheduled for the beginning
of November. The upgrade from 3.1 should be transparent for all but a
tiny minority of users. The beta differs from the final release in the
following ways:

o The PDF documentation is not included, because we're going to be
  generating it with a better tool which we haven't mastered
  yet. Also, the PDF document is significantly larger, due to the
  tutorial and its illustrations, and will be available via a separate
  download. 

o Time permitting, we will finally update the Python and Allegro
  binding documentation, which is somewhat stale. 

The GalaxyCommunicator 3.2beta1 distribution comes with extensive
documentation (see docs/index.html), a detailed list of new features
(see docs/new_features.html), and an upgrade guide for 3.1
installations to 3.2 (see docs/3point2upgrade.html).

Upgrade assistance and guidance is also available at
bug...@li.... Please direct all bugs, as usual, to
bug...@li...; please do not send mail directly to
members of the Communicator team.

The GalaxyCommunicator 3.2beta1 release is an open source
distribution. It is available at
http://communicator.sourceforge.net/download.

Samuel Bayer 
For the Communicator team 

[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

Re: [Communicator-user] Output

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

   Iam using the DARPA software for an agent based
   program. In this program the agent is supposed to
   output some lines of text in response to the user
   pressing a button(s). In this program the text that is
   supposed to come from the agent text that is preceded
   by SET PROP and String Object. Unfortunately the text
   is not being outputed as a response to the user
   pressing the buttons. Any ideas on how to get the text
   to execute? 

Without code, it's a little hard to tell what the story is. Can you
post an appropriate code fragment?

Cheers,
Sam

[Communicator-user] Output

[Mykeisha B. <my_...@ya...>]

Iam using the DARPA software for an agent based
program. In this program the agent is supposed to
output some lines of text in response to the user
pressing a button(s). In this program the text that is
supposed to come from the agent text that is preceded
by SET PROP and String Object. Unfortunately the text
is not being outputed as a response to the user
pressing the buttons. Any ideas on how to get the text
to execute? 

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

[Communicator-user] Announcing the release of Galaxy Communicator 3.1

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

All -

We are, as usual, pleased and relieved to announce the availability of
Galaxy Communicator 3.1. 

Version 3.1 is mostly a bug fix distribution, but there is also some
new functionality provided. 

o New Builtin server functions, to list the available servers and
  to call subprograms so that they return values 
o Cross-compilation support, for platforms such as the StrongARM 
o A vastly improved abstraction for the event-driven programming
  model used to embed Communicator servers in external main loops 
o Hub scripting improvements,including a new directive (IGNORE:),
  a new comparison (IN), and better write-locking for the global
  namespace. 

Please direct all bugs, as usual, to bug...@li...;
please do not send mail directly to members of the Communicator team. 

The GalaxyCommunicator 3.1 distribution comes with extensive
documentation (see docs/index.html), a detailed list of new features
(see docs/new_features.html), and an upgrade guide for 3.0
installations to 3.1 (see docs/3point1upgrade.html). Upgrade
assistance and guidance is also available at
bug...@li....

The GalaxyCommunicator 3.1 release is an open source distribution. It
is available at http://communicator.sourceforge.net/download. 

Samuel Bayer 
For the Communicator team 

P.S. MIT Galaxy users: Versions of the MIT Galaxy system released
before June 26, 2001 will not compile against Galaxy Communicator 3.0
or 3.1 without minor modifications. MITRE has a set of working
patches, which you may contact me directly in order to obtain. The
same set of patches works for both distributions.

[Communicator-user] fofoca website is back online

[John A. <abe...@mi...>]

Greetings all,

We're pleased to announce that MITRE's communicator website at:

http://fofoca.mitre.org/

is back online. You will find that there is less content on fofoca than 
you may remember. This is because much of the public content has been 
moved to:

http://communicator.sourceforge.net/

(the fofoca website has pointers to the public resources on the 
sourceforge website).

On the fofoca website is a Participant Resources page which lists items 
that are only available to Communicator participants (currently minutes 
of the Communicator Advisory Committee meetings -- other resources may 
be added at a later date). To access the participants resources you will 
have to register by filling out a form accessible from the Participants 
Resources page. Alternatively, you may go to the registration form 
directly:

http://fofoca.mitre.org/cgi-bin/register.cgi .

Please note that due to circumstances beyond our control, users who were 
previously registered on the fofoca website WILL HAVE TO REGISTER AGAIN. 
We apologize for the inconvenience.

After your registration information has been verified you will receive 
be granted access to the participants area. Please note that we are 
unable to offer user login accounts on fofoca at this time. Again, we 
apologize.

We thank you all for your patience during the fofoca downtime.

Sincerely,
John Aberdeen and The MITRE Communicator team.

--
John Aberdeen
The MITRE Corporation
abe...@mi...

[Communicator-user] Announcing the release of Galaxy Communicator 3.0

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

All - 

We are, as usual, pleased and relieved to announce the availability of
Galaxy Communicator 3.0.

Even though the internals of the infrastructure have changed in some
major ways, the upgrade from 2.1 to 3.0 will be quite simple for the
great majority of users. Version 3.0 features:

o Vastly improved tools for managing simultaneous sessions 

o More flexible and robust Hub-server interaction, including the
introduction of continuations and the elimination of deadlocks 

o Support for server location files, which help maintain consistent
port location information across Hub and server 

o Many infrastructure improvements, including cross-language support
for distinguishing among Galaxy Communicator versions, improved timed
task control, and a consistent, event-driven programming model for
embedding the Galaxy Communicator library

o Improvements in the frame library, including support for dynamically
expandable lists and arrays, better memory management options, and
access to the full range of Communicator types as frame fills

o More flexibility in the Hub syntax and organization, including
better management of servers and service types, new support for
choosing among available servers, and an alternative syntax which
provides a wider array of control options and eliminates some of the
idiosyncracies in the default syntax

o A completely revised communications protocol, including XDR encoding
for all brokering and message traffic and better encapsulation of
administrative information

o Significant brokering improvements, including access to the full
range of Communicator types for brokering and automatic support for
multiple subscribers for outgoing brokers

o A PDF version of the HTML documentation (thanks to
http://www.easysw.com and their open source conversion tool!)  

Please direct all bugs, as usual, to bug...@li...;
please do not send mail directly to members of the Communicator team.

The GalaxyCommunicator 3.0 distribution comes with extensive
documentation (see docs/index.html), a detailed list of new features
(see docs/new_features.html), and an upgrade guide for 2.1
installations to 3.0 (see docs/3point0upgrade.html). Upgrade
assistance and guidance is also available at
bug...@li....

The GalaxyCommunicator 3.0 release is an open source distribution. It
is available at http://communicator.sourceforge.net/download. (Note
that this distribution is not available at http://fofoca.mitre.org.)

Samuel Bayer 
For the Communicator team 

P.S. MIT Galaxy users: The MIT Galaxy system will not compile against
Galaxy Communicator 3.0 without minor modifications. MITRE has a set
of working patches, which you may contact me directly in order to
obtain.

P.P.S. For details on the development of version 3.0 and how it
responds to our original upgrade survey, see the on-line release
announcement at
http://communicator.sourceforge.net/download/3point0-announce.html.