communicator-user — Galaxy Communicator User Discussion List

Re: [Communicator-user] Two new problems

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

   Hi, it's me again

Hi.

   The first is when i call the server with no args it should exit and 
   print the usage line and it doesn't... And i have three arguments. It
   prints if a use only one agrument in all other cases except if i don't
   give any args. This is not a big problem i made a test to the value
   of argc. 

I'll need to see more of the code. If you're writing your own main(),
it can be a little tricky how the argument parsing works. If you can
tell me what specific command line invocations aren't doing what you
expect, that would help.

   The next and more challenging one is, when i send a message to the hub
   and this message should produce an error, like an operation that does,t
   exist, i receive the same message i sent, and i wanted to receive the
   error message which i see in the hub pane.

   [...]
     (ERROR:
   ------ System Warning/Error ------
   )
   {c system_error
      :server_unavailable 1
      :operation "k"
      :server_name "Echo"
      :session_id "Default"
      :tidx 2 }
     (ERROR: ------------------------------------

   )
	   [Destroying token 2]
   tokens:  1 (0)
   done with token 1 --> returning to owner UI@<remote>:-1
	   [Destroying token 1]
   [...]

This one's pretty straightforward, but I don't think you'll like the
answer much. When the Hub can't find an operation, it doesn't raise an
error in the token which the operation represents; instead, it creates
a new token which describes the error. The token which contains the
unrecognized operation is untouched. I have to agree that this seems a
little bizarre, but this particular dimension of error handling was
established before I took over the maintenance of the code, and I
somehow doubt that changing it would be very well received. So the
short answer is, you can't directly capture this error. 

The worst part about it is that if you're trying to send messages
directly, without using the Hub scripting, I can't think of any way
for you to capture the error at all. Oops. Is this a bug? Probably. If
you try to send an unrecognized message from the Hub to a server, the
server will raise an error as the response.

Unfortunately, I don't think I can fix this for version 4.0.

Sorry,
Sam

[Communicator-user] Two new problems

[bosnio <bo...@ne...>]

Hi, it's me again

First of all and once again, thanks to Samuel Bayes, you have solved my =
problem, i had it for a long time and i had tried almost everything.

Now i have two simple problems which i don't know if are bugs, or my =
problems.

The first is when i call the server with no args it should exit and =
print the usage line and it doesn't... And i have three arguments. It =
prints if a use only one agrument in all other cases except if i don't =
give any args.
This is not a big problem i made a test to the value of argc.

The next and more challenging one is, when i send a message to the hub =
and this message should produce an error, like an operation that does,t =
exist, i receive the same message i sent, and i wanted to receive the =
error message which i see in the hub pane.

Once again i send the interaction of the hub, and the server:

=20
------------------------HUB

Got new message from provider for UI (id 2)
M-M dialogue for provider for UI (id 2)

----------------[  1]----------------------
{c Echo.k
   :frase "O meu recebe isto"
   :session_id "Default"
   :tidx 1 }
----------------------------------------

  (ERROR:
------ System Warning/Error ------
)
{c system_error
   :server_unavailable 1
   :operation "k"
   :server_name "Echo"
   :session_id "Default"
   :tidx 2 }
  (ERROR: ------------------------------------

)
        [Destroying token 2]
tokens:  1 (0)
done with token 1 --> returning to owner UI@<remote>:-1
        [Destroying token 1]

--------------------------------SERVER

GalIO_CommDispatchFrame: sending new message:
{c UI
   :signatures (  )
   :properties {c server_properties }
   :extra_service_types (  )
   :protocol_version 1 }
GalIO_CommDispatchFrame: got reply:
{c UI
   :signatures (  )
   :properties {c server_properties }
   :extra_service_types (  )
   :protocol_version 1 }
GalIO_CommDispatchFrame: sending new message:
{c Echo.k
   :frase "O meu recebe isto"
   :hub_opaque_data {c admin_info
                       :reply_requested 1
                       :server_tidx 1 } }
GalIO_CommDispatchFrame: got reply:
{c Echo.k
   :frase "O meu recebe isto"
   :session_id "Default"
   :hub_opaque_data {c admin_info
                       :tidx 1
                       :session_id "Default"
                       :server_tidx 1 } }



----------------------



The frame in Red was the one i wanted to receive.

I will now present the source code that i am using



=20

char* sendMessageToHub(char* recvline, int argc, char* argv[], char* =
oas[])
{
 =20
  GalIO_ServerStruct *server;
  GalIO_CommStruct *new_comm;
  GalSS_Environment *env;
  int hubport;
  char* hubaddress;
  Gal_Frame request, reply;
  char* sendline[MAXLINE];  =20
  int i =3D MAXLINE;
  GalIO_MsgType t;


  memset(sendline,'\0',MAXLINE);
=20
  //Testar se a string e uma frame be formada
  request =3D Gal_ReadFrameFromString(recvline);

  GalUtil_OAExtract(argc, argv, oas, "-hubport", GAL_OA_INT, &hubport);  =

  GalUtil_OAExtract(argc, argv, oas, "-hubaddress", GAL_OA_STRING, =
&hubaddress);
 =20

  server =3D GalSS_CmdlineSetupServer(argc, argv);
  if(!server){
    GalUtil_Fatal("Failed to set up server!\n!");
  }


  if ((new_comm =3D GalIO_ContactHub(hubaddress, hubport, server, =
NULL,0)) =3D=3D NULL)
  {
    sprintf(sendline, "{c error :descrition \"Can't contact hub at port: =
%d , host: %s}", hubport, hubaddress);
    printf(sendline);
    return(sendline);
  }


  while(1){
    int res =3D GalIO_VerificationHandler(new_comm);

    if(res =3D=3D -1) {
      GalUtil_Fatal("Failed to confirm connection!\n");
    }else if (res =3D=3D 1) {
      break;
    }
  }

  env =3D GalSS_EnvCreate(new_comm);
  GalSS_EnvLock(env);
  reply =3D GalSS_EnvDispatchFrame(env, request, &t);
 =20

 /* if(!reply){
     =20
    } =20
*/

  switch(t){
  case GAL_REPLY_MSG_TYPE:
    printf("\n Mesnagem ok\n");
    break;
  case GAL_ERROR_MSG_TYPE:
    printf("\n Granda azar erro\n");
    break;
   =20
  }
 =20
=20
  GalSS_EnvUnlock(env);
 =20
 =20
  Gal_PrFrame(reply);
  Gal_PrFrameToString(reply,sendline, &i);=20
  Gal_FreeFrame(reply);
  Gal_FreeFrame(request);
  GalIO_DestroyCommStruct(new_comm);
  GalIO_DestroyServerStruct(server);
  return(sendline);
}


I am switching the return message type just for debug, because my server =
isn't supposed to do any processing it just passes the message to the =
webclient even if it is an error message. But the message i am receiving =
appear as a normal reply message and it should be an error one as we can =
see in the hub..



Once again thanks for the spared time

Jo=E3o Gra=E7a=20

[Communicator-user] Re: [darpacomm #947] Problem contacting the hub..

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

Hi again -

What a thorough bug report. 

   The problem is that the server contacts the hub sending him the a 
   message identifing himself and  receives a reply, but them when i send a
   message the hub does,t receive nothing.

I must apologize for using you as a guinea pig. I had forgotten that
when the Hub and the server establish a connection, the Hub ALWAYS
sends a "reinitialize" message to the server, and ALWAYS expects a
reply. If the server doesn't support the "reinitialize" message, it
simply returns the frame it's sent. This handshake is reliably hidden
most of the time, but I haven't hidden it in this case yet. So your
echoclient.c example should read as follows:

  ...
  new_comm = GalIO_ContactHub("localhost", 5000, server, NULL, 0);

  while (1) {
    int res = GalIO_VerificationHandler(new_comm);

    if (res == -1) {
      GalUtil_Fatal("Failed to confirm connection!\n");
    } else if (res == 1) {
      break;
    }
  }
 
  env = GalSS_EnvCreate(new_comm);
  GalSS_EnvLock(env);

  ...

The call to GalIO_VerificationHandler() satisfies the "reinitialize"
issue.  This is usually handled in the standard poll mechanisms, but
you're not using those, so this call is required. This is NOT
documented, and shouldn't need to be; in 4.0 I'll have this packaged
much better.

   Finaly i didn't quiet undestand how do you set the pool flags from what 
   i have read in the documentation... How can i set them without 
   GalSS_SAFixServerListenStatus, because here i must have an argument 
   package...and i don't need them anywhere else. Could you please try to 
   explain how do i work with the flags.

see "docs/manual/reference/server_structure.html#Listener-in-Hub support". 
You'll find a description of the flags which you can use. 0 is a safe
value, because (I think) the flags are ignored except in the normal
polling situation. 

Cheers,
Sam

[Communicator-user] Problem contacting the hub..

[bosnio <bo...@ne...>]

        Hello,=20
            First of all i would like to thank Samuel Bayer for the =
response to my previous e-mail.
I tried to put the code, that was sent in that e-mail but i wasn=B4t =
able to contact the hub in the proper way...

For a test i created a simple program that was supposed to connect to =
the hub send a message and receive a reply (if i can do this,i will be =
able to incorporate this in the child process of the system that i am =
trying to build, the one i explain in my last e-mail).

The problem is that the server contacts the hub sending him the a =
message identifing himself and  receives a reply, but them when i send a =
message the hub does,t receive nothing,,,,=20
I will present the interaction...

 This is the interaction of the echo_client, that follows the code on =
the last e-mail. (i will put the code at the end of the e-mail)
[bosnio@ninja MultipleWebClient]$ ./bin/EchoClient
GalIO_CommDispatchFrame: sending new message:
{c UI
   :signatures (  )
   :properties {c server_properties }
   :extra_service_types (  )
   :protocol_version 1 }
GalIO_CommDispatchFrame: got reply:
{c UI
   :signatures (  )
   :properties {c server_properties }
   :extra_service_types (  )
   :protocol_version 1 }
GalIO_CommDispatchFrame: sending new message:
{c SendRequest
   :frase "
O meu recebe esta merda
"
   :hub_opaque_data {c admin_info
                       :reply_requested 1
                       :server_tidx 1 } }


Now in the hub intercation, it appears that a socket has been open, but =
nothing more:

Hub iteraction

=20

[bosnio@ninja MultipleWebClient]$ hub -pgm_file MultipleWebClient.pgm
Reading MultipleWebClient.pgm
Done reading MultipleWebClient.pgm (15 lines)
3 service types
1 service providers
1 programs


--------------------------------------------------
service type: UI : 5000
Opening listener UI
Trying to set up listener on port 5000
reset_listener called
GalIO_ServerStart: Listening on port 5000

--------------------------------------------------
provider: for echo @ localhost:10000
GalIO_CommDispatchFrame: sending new message:
{c handshake
   :conn_type 1
   :protocol_version 1 }
GalIO_CommDispatchFrame: got reply:
{c echo
   :signatures ( ( "echo"
                   (  )
                   2
                   6
                   (  )
                   2 ) )
   :properties {c server_properties }
   :extra_service_types (  )
   :protocol_version 1 }
connected to provider for echo @ localhost:10000.

--------------------------------------------------
........__GalIO_ServerContactHandler: connected to 127.0.0.1 (sock=3D8)=20

The part in red is what appears when i start the client.

The echo server doesn't appear anything, and it should receive a message =
invocking his echo dispatch function.

The interaction:
=20
[bosnio@ninja MultipleWebClient]$ ./bin/Echo
reset_listener called
GalIO_ServerStart: Listening on port 10000
__GalIO_ServerContactHandler: connected to 127.0.0.1 (sock=3D7)


So this is my actual problem which i can't solve.... I hope that someone =
could help me.

I am know sending m actual PGM file and the source code of echo_client =
so that you can have a more precise look of what i am doing.


=20
---->PGM_FILE

SERVER: echo
PORT: 10000
HOST: localhost
OPERATIONS: echo=20

SERVER: UI
CLIENT_PORT: 5000
OPERATIONS: sendRequest

PROGRAM: SendRequest

RULE: --> echo
IN: :frase
OUT: :resposta


----->echoclient.c

#include "galaxy/galaxy_all.h"
#define SERVER_FUNCTIONS_INCLUDE "MultipleWebClient.h"
#define USE_SERVER_DATA
#include "galaxy/server_functions.h"


int main(int argc, char* argv[])
{
  GalIO_ServerStruct *server;
  GalIO_CommStruct *new_comm;
  GalSS_Environment *env;
=20
   char* reply;
   Gal_Frame new_f =3D Gal_MakeFrame("SendRequest", GAL_CLAUSE);
   Gal_Frame res_f;
   GalIO_MsgType t;


 =20
  server =3D GalSS_CmdlineSetupServer(argc, argv);
  if(!server){
    GalUtil_Fatal("Failed to set up server!\n!");
  }


  new_comm =3D GalIO_ContactHub("localhost", 5000, server, NULL,-1);
 =20
 =20
  env =3D GalSS_EnvCreate(new_comm);
  GalSS_EnvLock(env);


  Gal_SetProp(new_f, ":frase", Gal_StringObject("\nO meu recebe esta =
merda\n"));
  res_f =3D GalSS_EnvDispatchFrame(env, new_f, &t);
  Gal_FreeFrame(new_f);
  //Falta aqui uns testes do que o mano recebeu
  reply =3D Gal_GetString(res_f, ":resposta");
  printf("/nOk o que o Ze dread disse foi: %s/n",reply);
  Gal_FreeFrame(res_f);


  GalSS_EnvUnlock(env);
}

---->echo_client.h
GAL_SERVER_NAME(UI)
GAL_SERVER_PORT(5000)

----->echo.c
#include "galaxy/galaxy_all.h"
#define SERVER_FUNCTIONS_INCLUDE "echo.h"
#define USE_SERVER_DATA
#include "galaxy/server_functions.h"

Gal_Frame echo(Gal_Frame frame, void *server_data)
{
  char* msg =3D Gal_GetString(frame, ":frase");
  printf("\n Recebi a mensagem: %s \n",msg);
  Gal_SetProp(frame, ":resposta", Gal_StringObject(" Ok mano recebi a =
tua dica"));
  return frame;
      =20
}


----->echo.h

GAL_SERVER_NAME(echo)
GAL_SERVER_PORT(10000)
GAL_SERVER_OP(echo)
=20

-----------------------------------------------------------

So my problem is that it seems that i am contacting the hub, but after i =
receive my first message i can't send no more messages because they =
don't arrive at the hub.=20
Finaly i didn't quiet undestand how do you set the pool flags from what =
i have read in the documentation... How can i set them without =
GalSS_SAFixServerListenStatus, because here i must have an argument =
package...and i don't need them anywhere else. Could you please try to =
explain how do i work with the flags.

Thanks for the spared time, best Regards

Jo=E3o Gra=E7a=20

Re: [Communicator-user] Sending a message to the hub...

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

   I am trying to build a Hub Client.

   It is supposed to have an open port, which receives connection using a 
   common TCP-IP socket. For each accept connection it will create a child 
   (fork), on this child i would like to read the message from the socket, 
   connect to the hub send the message, receive the reply send it throw the 
   socket and close all connections and exit.

   I wanted to set the server with GalSS_cmdlineSetupServer... but when i 
   call GalSS_StartandRunServer i lose the control, because all the 
   interection with reinitialize and the time task loop begins... Is it 
   possible to simply start the server, send the message, await for reply 
   and then shut down... How can this be done?

This is one of the things we need to fix for 4.0. There's a simple way
to contact a server pretending to be the Hub (GalIO_ClientConnect),
but not necessarily a simple way of contacting the Hub as a
server. Try this:

  GalIO_ServerStruct *server;
  GalIO_CommStruct *new_comm;
  GalSS_Environment *env;
  
  server = GalSS_CmdlineSetupServer(argc, argv);
  if (!server) {
    GalUtil_Fatal("Failed to set up server!\n");
  }

  /* Assuming you have the host, port, and you've determined
     what your poll flags are (see the documentation for
     GalIO_ServerListenStatus) */
  new_comm = GalIO_ContactHub(host, port, server, (char *) NULL,
                              poll_flags);
  /* At this point, you should be able to send a message to the 
     Hub and get its reply using GalSS_EnvDispatchFrame(). */
  env = GalSS_EnvCreate(new_comm);
  GalSS_EnvLock(env);
  /* build your message, get the reply. */
  reply = GalSS_EnvDispatchFrame(env, ....);
  GalSS_EnvUnlock(env);
  /* etc. More cleanup: free frames, destroy the connection and 
     server. */

This ought to be a little simpler, and it ought to be in the docs. If
this doesn't work, send more mail to this list or to
bug...@li... and we'll work it out.

Cheers,
Sam Bayer

[Communicator-user] Sending a message to the hub...

[bosnio <bo...@ne...>]

I am trying to build a Hub Client.

It is supposed to have an open port, which receives connection using a =
common TCP-IP socket. For each accept connection it will create a child =
(fork), on this child i would like to read the message from the socket, =
connect to the hub send the message, receive the reply send it throw the =
socket and close all connections and exit.

I wanted to set the server with GalSS_cmdlineSetupServer... but when i =
call GalSS_StartandRunServer i lose the control, because all the =
interection with reinitialize and the time task loop begins... Is it =
possible to simply start the server, send the message, await for reply =
and then shut down... How can this be done?

Thanks for your help

Jo=E3o Gra=E7a=20

RE: [Communicator-user] GCSI and web services ? What do you think ?

[Cristi U. <c....@sh...>]

> Are the specs neutral? I can't find any evidence on the Web that the
> .NET CLR has been submitted to any standards body (it certainly
> doesn't help that Microsoft keeps choosing names for things, like .NET
> and C#, which include punctuation which Google strips off).

CLR (Common Language Runtime) with MSIL (Microsoft Intermediate
Language) from .NET is Microsoft's response to Sun's JVM (Java Virtual
Machine) and its bytecode language. It is part of .NET which is one of
the "instances" of Web Services. Another Web Service instance or
implementation is JAX provided by Sun. It is just like the WEB browsers
situation a long time ago. 

Web Services are under the "control" of W3C. They resulted as a unified
effort from all the major players. The Web Services specs
(http://www.w3c.org/2002/ws) relay mostly on 3 major XML languages:

WSDL (http://www.w3c.org/TR/wsdl) - describes a Web Service interface in
machine readable form.

XSD or XML Schema (http://www.w3c.org/XML/Schema) - describe any kind of
data type that would be passed between WS. 

SOAP (http://www.w3c.org/TR/2001/WD-soap12-part0-20011217) - describes
RPC in XML.

I wrote all the thighs above just to state that it appears to be the
most neutral situation in the history of RPC solutions. This is very
good because it kills the stupid rivalry between various standards that
prevented things from happening at a real BIG scale. 

> Submitting Web services as standards is a real risky
> proposition for these companies: on the one hand, they can't really
> take off unless there's true distributed access to them, which means
> other platforms and other vendors, but the loss of control implied
> there also calls into question what the business model might be.

Well this is why thighs are really exciting here. :)) It's really a race
and rivalry between implementations and not between standards. This is
very good and healthy. All those implementations will coexist finally.
Of course that there is always the danger that one implementation will
try to modify the standards so it can take advantage (like MS did with
its web browser)... but let's hope this time won't be as bad as before.
:))

> I do take your point here; I'm just not sure I agree. I think CORBA
> reall does count as a non-neutral specification; there are open-source
> implementations of it for a number of languages, and if I recall
> correctly, the Java runtime now comes with an ORB. And it's not clear
> that there's anything wrong with CORBA, technically, except for the
> judgment I've frequently heard that it's too heavyweight a
> protocol. That is, it's not clear to me that the battle has changed
> substantially; but I can't really judge this well.

Perhaps CORBA is the most neutral solution that existed so far. It was
supported only by a group of the big players and I think it is a living
example of what rivalry can do to a good solution.  

Web Services in essence are common SEMANTICS (SOAP, WSDL, XSD) over a
common SYNTAX (XML) and they have the implicit/explicit support of all
major players. It's a really remarkable fact that has a big potential. 
 
> How do you make a speech
> recognizer sensitive to context? Do you just swap the language model,
> or is there something more sophisticated you can do? 

Do you mean real time language detection? We are hopping to work with
recognizers that are able to detect the language as you speak...but they
are prototypes I guess. 

> Furthermore, the apparent advantage of not needing to support a
> service you don't know much about vanishes in real research
> circumstances. Let's say I wrote a parser which wasn't perfect, and
you
> needed some help. But I'm running it as a service, and you don't have
> the source code. And there are twenty other groups ALSO subscribing to
> my service, and they're having problems as well. Do you really want to
> wait for me to get around to paying attention to you, or would you
> prefer the option of rolling up your sleeves and trying to fix the
> problem yourself?

The answer is that with your example, perhaps not. I would try to solve
the problem by myself :))

But with the Google example, there is not too much hope to get it to run
locally. Personally, I would trust Google for support with their IR
system as a web service. The API they offered is like a toy for small
developers to show what it can do, to show the potential.

I am sure Google already plans B2B with the big portals and commercial
sites and it will do it through Web Services.

> Or let's say there's an enhancement you'd like to
> see installed, because of some complex set of dialogues you're
> exploring. In other words, I think it's far more likely that
> researchers are going to WANT to have other people's code and run it
> locally, rather than rely on the apparent simplicity of subscribing to
> a remote service.

Sam,

It looks like there are examples where you are right and people would
want to get their hand dirty even if it's not their job and there are
examples where I am right. One can have both things happening on his
site. Getting the code to run on one's local machines is something that
happens today and it's not very difficult to be done. The problem
becomes more difficult when it comes to accessing remote services. There
seems to be a solution to this one in the not distant future and I
personally wandered if this can be exploited in future by GCSI.

> I realize I'm stating my case awfully strongly here. If the AMITIES
> folks really have firewall issues and distributed interaction
> requirements that the GCSI doesn't address, we need to talk about that
> (offline, of course). But as long as this is an abstract issue, I'm
> going to try to stick to my guns.

I didn't start this discussion because of some firewall issue we have
here or because of some distribute requirements that we have on AMITIES.
Apart from multilingual support (that was very rapidly solved by you
guys, thank you very much again) there is no other real and strong
requirement for us from GCSI. It works very well and I am happy with it
the way it is right now. For the moment you won this friendly debate.
:))

I was trying to look in the near future, I've combined Web Services
specs with the GCSI distributed design, I got excited :)) and I wrote
the first e-mail to the GCSI user discussion group hopping to get some
opinions. I received plenty of them from you and I thank you very much
for taking time to read and to answer. 

Cheers a lot for this comprehensive and pleasant, for me at list,
discussion I had with you.

cristi

Re: [Communicator-user] GCSI and web services ? What do you think ?

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

   > Consider, for instance, the "flavor of the month" problem in remote
   > service models. First it was CORBA, then RMI, then JINI or JavaBeans
   > or whatever the hell it was at that point, now it's .NET and JAX.

   On a first view Web Services are not very different than CORBA,
   DCOM, RMI, RPC, etc. In fact they are the same thing in terms of
   functionality.  The novelty here is that they bring into light a
   neutral standard. All the previous tries were customized protocols
   and products that were fighting against each other for
   supremacy. Now the specs are neutral and they have been embraced by
   the big players. All they have to do now is to start producing
   implementations for it. To me is just like when the WEB (HTML/HTTP)
   started. Netscape and MS produced implementations for them and the
   browsers war started. Now we are talking about the war between .NET
   and JAX and perhaps other implementations. This is the clue to me
   that make me think that this time they got it right and Web
   Services will be the next BIG thing that every body was expecting.

Are the specs neutral? I can't find any evidence on the Web that the
.NET CLR has been submitted to any standards body (it certainly
doesn't help that Microsoft keeps choosing names for things, like .NET
and C#, which include punctuation which Google strips off). And the
histories of Microsoft and Sun don't give me much confidence that this
will happen. Granted, SOAP is being worked on by the W3C, and
Microsoft deserves kudos for that, and Sun has certainly put a number
of things in the public domain (like XDR, which we use in the
GCSI). Submitting Web services as standards is a real risky
proposition for these companies: on the one hand, they can't really
take off unless there's true distributed access to them, which means
other platforms and other vendors, but the loss of control implied
there also calls into question what the business model might be.

I do take your point here; I'm just not sure I agree. I think CORBA
reall does count as a non-neutral specification; there are open-source
implementations of it for a number of languages, and if I recall
correctly, the Java runtime now comes with an ORB. And it's not clear
that there's anything wrong with CORBA, technically, except for the
judgment I've frequently heard that it's too heavyweight a
protocol. That is, it's not clear to me that the battle has changed
substantially; but I can't really judge this well.

   It is true that SOAP over HTTP is not very reliable but it's a good
   start for the moment. I remember when credit card transaction over the
   Internet begun. It wasn't very safe :)) (you know what I mean) but
   things improved. I heard that the plans for the future stipulate that
   HTTP will be discarded and SOAP will take over. Of course that security
   will never disappear, as well as the firewall issue. They have always
   been there and we have to live with them but they shouldn't stay in our
   way.

I actually have no doubt about its reliability; it's a matter of how
long it will remain under the radar security-wise that concerns me.

   > The XML issue is another hot button for me, unfortunately. XML has
   > at least two serious disadvantages as an on-the-wire transport: first,
   > it's way too verbose, and second, it has no real datatypes besides
   > "string".

   The first disadvantage you present here can bee seen as an
   advantage if we are talking about DEBUGGING. Too verbose means that
   it facilitate human debugging but this comes to the price of being
   slow and taking some bandwidth. The last things will improve
   because it's a hardware problem.  The same has been said about Java
   and it's still around today making the developer's life more
   comfortable.

I'll certainly grant that when I'm trying to figure out what went over
the wire, it's harder than it would be if only ASCII were going over
the wire. However, the situations where anyone besides me would need
to look at that data are exceedingly rare. I certainly agree that in
the best of circumstances, a fatter pipe will address the verbosity
problem, but there are actually some circumstances which I have to
worry about (military contexts, mostly) where the bandwidth is
exceedingly narrow. So I need to pay attention to this issue. I don't
actually believe that processor speed is relevant here, since its
effect is pretty much swamped by network latency in most of the
situations I'm familiar with.

   The second one has been overcome with the arrival of XSD or XML Schema
   maintained by W3C. Web Services couldn't happen without agreeing on a
   standard that regulates the small details that make life so painful
   like: (what is the length of an Integer, or what is the encoding of a
   String). It's being done. Now you can encode any data type with XSD.
   There is a standard agreement and the big players started to implement
   it. It's a very important aspect for the future.

I'd somehow missed this standards effort. Thanks.

   > So let's say, on the other hand, that a researcher wants to stand up a
   > Web service for free. This is certainly not out of the question. But
   > first, it has to address the issue I raised earlier, namely, why a
   > researcher would tolerate relying on someone else's code on a machine
   > he/she doesn't have control over. For me and people in my lab, it's a
   > last resort, especially given the plummeting cost of hardware. But
   > let's say someone wants to interact in that way. Why use JAX or .NET?
   > What are the advantages? You list some.

   Well as you spotted a disadvantage of web services will be the fact
   that "no one will tolerate relying on someone else's code on a
   machine he/she doesn't have control over". But to me this sounds
   like an immense pressure for that ONE because ONE is forced to
   learn lots of things in order to be able to cope with minor/major
   problems. It is just like learning to repair everything in a house
   hold. Instead of relying on specialized services ONE would try to
   apply a DIY "strategy".

   [...]

   In my domain there are groups of researchers doing very well one task
   and doing very badly some other tasks. For example in a NLP system one
   would need to carry a POS (part of speech) operation. To me this should
   be a Web Service accessible worldwide. GOOGLE already took this step
   with its GOOGLE API (http://www.google.com/apis/) offering NLP
   applications a nice and powerful IR system. :))

There are certainly some mature technologies to exploit, like POS
tagging. But if they're really mature and bulletproof, then it's just
as easy to install the code locally and run it yourself as try to
access it over the network. Granted, if it really ISN'T mature, and
you need to engage the developer in fixing it for you, there may be a
debugging advantage in your request running on his server instead of
yours. My experience as been, however, that none of these technologies
has been used in the range of situations which would mostly permit
them to be run out of the box if a researcher is really interested in
exploring advanced dialogue, because the interactions between these
modules have gone largely unexplored. How do you make a speech
recognizer sensitive to context? Do you just swap the language model,
or is there something more sophisticated you can do? It seems to me
that a lot of people are going to want to get into this dimension of
things, and to do that, you need the code. That is, you're right that
people shouldn't have to roll up their sleeves and get their fingers
dirty in things they don't have expertise in, but my experience has
been that people can't afford NOT to, because the problem of spoken
dialogue appears to be a tightly integrated problem. 

Furthermore, the apparent advantage of not needing to support a
service you don't know much about vanishes in real research
circumstances. Let's say I wrote a parser which wasn't perfect, and you
needed some help. But I'm running it as a service, and you don't have
the source code. And there are twenty other groups ALSO subscribing to
my service, and they're having problems as well. Do you really want to
wait for me to get around to paying attention to you, or would you
prefer the option of rolling up your sleeves and trying to fix the
problem yourself? Or let's say there's an enhancement you'd like to
see installed, because of some complex set of dialogues you're
exploring. In other words, I think it's far more likely that
researchers are going to WANT to have other people's code and run it
locally, rather than rely on the apparent simplicity of subscribing to
a remote service.

I realize I'm stating my case awfully strongly here. If the AMITIES
folks really have firewall issues and distributed interaction
requirements that the GCSI doesn't address, we need to talk about that
(offline, of course). But as long as this is an abstract issue, I'm
going to try to stick to my guns.

Cheers,
Sam

RE: [Communicator-user] GCSI and web services ? What do you think ?

[Cristi U. <c....@sh...>]

Sam,

I am sure that my proposal for Web services into GSSI is very early and
all I wanted to do is to start a discussion around this subject that
will be benefic for us. For me at list it was. I am very glad that GCSI
has a good design that in my views still calls for Web Service support.
:))

Now I do realize that perhaps is still early for something like this and
to finish this subject I would like to say a few things that in my view
are a bit different than what you said.

> Consider, for instance, the "flavor of the month" problem in remote
> service models. First it was CORBA, then RMI, then JINI or JavaBeans
> or whatever the hell it was at that point, now it's .NET and JAX.

On a first view Web Services are not very different than CORBA, DCOM,
RMI, RPC, etc. In fact they are the same thing in terms of
functionality. 
The novelty here is that they bring into light a neutral standard. All
the previous tries were customized protocols and products that were
fighting against each other for supremacy. Now the specs are neutral and
they have been embraced by the big players. All they have to do now is
to start producing implementations for it. To me is just like when the
WEB (HTML/HTTP) started. Netscape and MS produced implementations for
them and the browsers war started. Now we are talking about the war
between .NET and JAX and perhaps other implementations. This is the clue
to me that make me think that this time they got it right and Web
Services will be the next BIG thing that every body was expecting.

It is true that SOAP over HTTP is not very reliable but it's a good
start for the moment. I remember when credit card transaction over the
Internet begun. It wasn't very safe :)) (you know what I mean) but
things improved. I heard that the plans for the future stipulate that
HTTP will be discarded and SOAP will take over. Of course that security
will never disappear, as well as the firewall issue. They have always
been there and we have to live with them but they shouldn't stay in our
way.
 
> The XML issue is another hot button for me, unfortunately. XML has
> at least two serious disadvantages as an on-the-wire transport: first,
> it's way too verbose, and second, it has no real datatypes besides
> "string".

The first disadvantage you present here can bee seen as an advantage if
we are talking about DEBUGGING. Too verbose means that it facilitate
human debugging but this comes to the price of being slow and taking
some bandwidth. The last things will improve because it's a hardware
problem. 
The same has been said about Java and it's still around today making the
developer's life more comfortable.

The second one has been overcome with the arrival of XSD or XML Schema
maintained by W3C. Web Services couldn't happen without agreeing on a
standard that regulates the small details that make life so painful
like: (what is the length of an Integer, or what is the encoding of a
String). It's being done. Now you can encode any data type with XSD.
There is a standard agreement and the big players started to implement
it. It's a very important aspect for the future.

> Next, there's the issue of whether the notion of "Web services" makes
> any sense at all. At the moment, we're already facing a crisis on the
> Net about profit-making; people want information, but they aren't
> willing to pay for it, at least given the current payment models. I
> personally would be happy to pay five cents per article view in a lot
> of places, but there's no established system of micropayments that
> seems to be both workable and acceptable from a human-factors
> standpoint. So how are Web services going to be successful? Why would
> people stand up a service? I doubt that it would cost any less than
> standing up information. In other words, I'm not sure the underlying
> business model has a whole lot of validity.

I agree with you. I would like to be able to work in an environment
based on micro payments that guarantee high quality information or
services. That will happen in a not very distant future.

The first to take advantage of the arrival of the Web Services would be
the B2B (Business 2 business) sector. They would be able to exchange
good services based not on micro payment of course :)) Improving B2B
will result in an improvement of B2C. After taking this step the focus
will be on directly improving B2C through means of micro payments.

> So let's say, on the other hand, that a researcher wants to stand up a
> Web service for free. This is certainly not out of the question. But
> first, it has to address the issue I raised earlier, namely, why a
> researcher would tolerate relying on someone else's code on a machine
> he/she doesn't have control over. For me and people in my lab, it's a
> last resort, especially given the plummeting cost of hardware. But
> let's say someone wants to interact in that way. Why use JAX or .NET?
> What are the advantages? You list some.

Well as you spotted a disadvantage of web services will be the fact that

"no one will tolerate relying on someone else's code on a machine
he/she doesn't have control over". But to me this sounds like an immense
pressure for that ONE because ONE is forced to learn lots of things in
order to be able to cope with minor/major problems. It is just like
learning to repair everything in a house hold. Instead of relying on
specialized services ONE would try to apply a DIY "strategy". 

The way they are right now, Web Services are not suited for Real time
tasks. A dialogue system can bee seen as a Real time system because the
user cannot wait forever to carry on a dialogue. This is why I say that
my proposal is too early and somehow not suited yet. However from this
discussion it emerged to me very clearly that for researchers, Web
Services are a real bless. They will really facilitate the
interoperability between sites.

In my domain there are groups of researchers doing very well one task
and doing very badly some other tasks. For example in a NLP system one
would need to carry a POS (part of speech) operation. To me this should
be a Web Service accessible worldwide. GOOGLE already took this step
with its GOOGLE API (http://www.google.com/apis/) offering NLP
applications a nice and powerful IR system. :))

Things started to move and first time I heard about Web Services I've
dismissed them as just another CORBA. When I started to read more about
them it revealed to me that they are not as they appeared to be. 

Thank you very much for taking time to read this.

cristi

Re: [Communicator-user] GCSI and web services ? What do you think ?

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

   Sam,
   You are right but practically CGSI runs with success on a local network
   and only theoretically over the Internet. If the bandwidth will grow the
   network latency issue will be overcome eventually, but the firewall
   issue will be there for ever and ever. Web services make possible to
   overcome the firewall problem because they are build on top of HTTP and
   use XML (SOAP) to communicate.

Let's be fair: it runs more than theoretically over the Internet. The
firewall issue is an obstacle, no doubt, but I would seriously be
surprised if SOAP over HTTP is the answer even in the medium term. The
reason is simple: SOAP over HTTP works because everybody thinks HTTP
is safe. The instant Web services become prevalent, and the instant
there's a security breach because you could do remote object
manipulation over HTTP, there's going to be a clamor to do more
"intelligent filtering" of HTTP traffic, and the firewall issue will
reappear in another form. Right now the filtering is pretty crude;
it's done by ports, because people conceive of ports as being
essentially equivalent to services. As soon as that equivalence is
broken, the current firewall model will fall apart, and the apparent
advantage of object manipulation over HTTP will vanish. I'm frankly
surprised this hasn't happened already with CGI; I know that our
sysadmins are very, very careful about what they allow as CGI scripts,
and it seems to me that Web services will receive even more scrutiny. 

The XML issue is another hot button for me, unfortunately. XML has
at least two serious disadvantages as an on-the-wire transport: first,
it's way too verbose, and second, it has no real datatypes besides 
"string". It's not even remotely clear to me what the advantage of
using it is over, say, a well-defined XDR encoding of object
transport, or, to take another example, CORBA IIOP. I agree that XML
is a great advance for document structure, but that doesn't mean it
should be the basis of a transport layer. I know it's possible to do
some intelligent compression of XML traffic, i.e., sending some data
description in XML across during the initial handshake, and just
wrapping uninterpreted data in XML for the remainder of the transport;
but at that point, are you even using XML, really? In other words,
it's either too verbose over the wire or it's a buzzword.

   > If someone wanted to start a
   > cottage industry running GCSI-compliant servers 24/7, I don't think
   > there's anything to prevent them from doing so right now; the "parser
   > server in Kansas" model is certainly something we originally aimed to
   > support.

   The firewall issue will prevent them from doing this and there is also
   the standards issue. You said that originally you aimed to support
   "parser server in Kansas" model. What happened with it? 

If there's no firewall, you can still do it. Stand up a parser at
Sheffield and have someone in Germany contact it (or someone in the
States). It works just fine. The reason people don't do it is that in
general, researchers appear to want to have their hands on the code
they're relying on. They don't want to worry about someone else's
machine crashing, or someone else's sysadmin being incompetent, or
someone else's bug causing them a headache they can't address. Not to
mention the fact that dialogue systems are sensitive to latency, and
my guess is that even the GCSI running locally is too much transport
overhead for some people. If the code is open source (and almost all
the code I work with is), people are going to want to have it locally,
because there's no comparative advantage to running it remotely. The
"parser server in Kansas" model is transparently supported; it's just
not used because it turns out to be the wrong model for research, at
least in the US. And it's not the firewall issue which is causing
people not to do it.

   I am a great admire of the GCSI and I think you guys did a wonderful job
   with it, but because I like it very much I am interested to see how it
   can be enhanced and made more flexible. In order to do this, one needs
   to try to spot its weaknesses.

   In my view standards compliance is a considerable issue to be taken into
   consideration. One of the advantages that web servers bring in is this
   standard the compliance. Currently there are two main implementations of
   the web services standards (JAX and .NET). 

   If the hub will be rewritten in one of the new language programming,
   Java for example, the frame data structure will be rewritten in XML
   (XSchema for example) and the servers libraries updated to comply with
   web services standards then CGSI will do the same stuff that it does
   right now, but it will be more powerful (better multimodal interaction
   support, multilanguage support through UNICODE, real functionality over
   the Internet) and more flexible because it will use widely available
   standards.

I appreciate your viewpoint, but after giving it some substantial
consideration over the years, I've arrived at a rather different
conclusion. Here's why.

The original goal of the GCSI was to "lower the bar to entry" for
spoken dialogue research. The original model presented to us by the
Communicator program manager was a DARPA program called MOSIS, which
was designed to promulgate best practice about VLSI design throughout
the universities and research labs, which led to an explosion in
training for VLSI designers. We believe very strongly in this model,
and it's been pretty successful so far, to my mind, due to a
confluence of factors: the insistence on the part of the DARPA program
that everyone use the GCSI; MIT's original contribution of its
software infrastructure as the basis of the GCSI and MITRE's assigned
role as its maintainer and designer independent of any dialogue
research agenda; the fact that the GCSI was assigned a generous
open-source license; and the continued endorsement by organizations
like CMU who develop high-quality, open source dialogue components. 

But the GCSI was never intended to be a production system. It's robust
enough to use it for research and prototype development, and to gather
real, high-quality data about human-computer interaction; but even
though its license permits it, it's not going to be part of a fielded
product, for all sorts of reasons beyond the standards issues: it's
not redundant, it's not secure, it doesn't integrate with existing IVR
systems, and I sincerely doubt that it would scale to thousands of
users. These are product-level issues which neither DARPA nor MITRE
ought to be addressing; the marketplace should be addressing them. 

So my first answer is: in principle, the world of GCSI is pretty
separate from the commercial world. Had the relevant standards been
available when we started, we might have consumed them; but they
didn't, and in some ways that was a good thing for us. I actually
don't see the particular advantage in conforming to emerging
standards. 

Consider, for instance, the "flavor of the month" problem in remote
service models. First it was CORBA, then RMI, then JINI or JavaBeans
or whatever the hell it was at that point, now it's .NET and JAX. I
have to tell you, I'm quite skeptical about whether either of those
service models will be any more successful than previous ones. Sure,
.NET has Microsoft behind it, but it's a lot harder to own the Net
than it is to own individual desktops, and if it ever turns out that
there's no money in it for Microsoft (e.g., if people don't go for
Hailstorm and Passport), Microsoft's enthusiasm will wane. And let's
face it, when you're dealing with things which aren't on your desktop,
trust becomes much more of an issue, and Microsoft, frankly, is not a
trustworthy company, and people know it. And as for JAX, I do a lot of
reading, and I'd never even heard of it until you mentioned it (I'll
leave it for you to decide whether that speaks worse of me or of
JAX). My skepticism about the likely success of these approaches may
be unwarranted, but their track record isn't good.

Next, there's the issue of whether the notion of "Web services" makes
any sense at all. At the moment, we're already facing a crisis on the
Net about profit-making; people want information, but they aren't
willing to pay for it, at least given the current payment models. I
personally would be happy to pay five cents per article view in a lot
of places, but there's no established system of micropayments that
seems to be both workable and acceptable from a human-factors
standpoint. So how are Web services going to be successful? Why would
people stand up a service? I doubt that it would cost any less than
standing up information. In other words, I'm not sure the underlying
business model has a whole lot of validity.

So let's say, on the other hand, that a researcher wants to stand up a
Web service for free. This is certainly not out of the question. But
first, it has to address the issue I raised earlier, namely, why a
researcher would tolerate relying on someone else's code on a machine
he/she doesn't have control over. For me and people in my lab, it's a
last resort, especially given the plummeting cost of hardware. But
let's say someone wants to interact in that way. Why use JAX or .NET?
What are the advantages? You list some.

(1) Firewall access: I've already argued that this advantage will
    vanish.

(2) Better multimodal support: it's not clear to me how Web services
    confer an advantage in this area.

(3) Multilanguage support through UNICODE: absolutely, this is missing
    from the GCSI, but again, it's not clear to me how Web services
    confer an advantage in this area. There are two issues as far as
    the GCSI is concerned regarding non-ASCII character sets: the
    transport layer and the client API. The client API would have to
    be fixed no matter what, and I can't believe the transport layer
    would be complicated. So we may get SOMEthing for free, but it
    doesn't seem to me that we'd get much.

(4) More flexible because of widely available standards: I just don't
    see this. There would have to be some marginal advantage in people
    investing in one of these object models over and beyond their work
    with the GCSI, and there just isn't enough motivation, it seems to
    me. For instance,  if you're trying to leverage commercial
    products, why buy a Web service from IBM for ViaVoice when you can
    buy the SDK and run it locally? Furthermore, the real interesting
    work in SR and TTS are being done in the laboratory, and
    tools like Sphinx and Festival are open source and run on multiple
    platforms, so why would you use ViaVoice for research unless you
    had the source code, like IBM? Finally, there aren't any other
    tools (besides, perhaps, VoiceXML) that would provide any
    comparative market advantage for researchers. 

So here's what I see when I look at the idea of Web services:

(a) an overly verbose wire protocol; 
(b) a "flavor of the month" problem with picking the right service
    model; 
(c) attention to an implied development model which doesn't seem to
    match what researchers do.

What this adds up to, for me, is a lot of work with not a lot of
payoff. If somebody else wants to do it, I think that would be great;
for instance, I've advocated for many years that someone build a
wrapper for VoiceXML so that we can do some baselining against current
market capabilities. But as with that effort, I've concluded that it's
just not what we're being asked to do here.

Cheers,
Sam

RE: [Communicator-user] GCSI and web services ? What do you think ?

[Cristi U. <c....@sh...>]

> After all, you don't need to be running your components locally; you
> can set up your Hub to contact them anywhere. I can run a Hub here at
> MITRE which contacts one of your servers at Sheffield, and except for
> latency and firewall issues (which you'll encounter with any Web
> service), everything will still work.

Sam,
You are right but practically CGSI runs with success on a local network
and only theoretically over the Internet. If the bandwidth will grow the
network latency issue will be overcome eventually, but the firewall
issue will be there for ever and ever. Web services make possible to
overcome the firewall problem because they are build on top of HTTP and
use XML (SOAP) to communicate.

> If someone wanted to start a
> cottage industry running GCSI-compliant servers 24/7, I don't think
> there's anything to prevent them from doing so right now; the "parser
> server in Kansas" model is certainly something we originally aimed to
> support.

The firewall issue will prevent them from doing this and there is also
the standards issue. You said that originally you aimed to support
"parser
server in Kansas" model. What happened with it? 

>    Tomorrow maybe, in order to build a GCSI based dialogue system, one
>    would only need to download and compile the HUB and start writing a
HUB
>    program that will integrate various GCSI servers available as web
>    services...
> 
> In other words, "today maybe". Am I missing something? If the issue is
> standards compliance, I can certainly see your point, but if the issue
> is (very-)remote access, I'm not sure I understand the problem.

No, the issue is not very remote access.
I am a great admire of the GCSI and I think you guys did a wonderful job
with it, but because I like it very much I am interested to see how it
can be enhanced and made more flexible. In order to do this, one needs
to try to spot its weaknesses.

In my view standards compliance is a considerable issue to be taken into
consideration. One of the advantages that web servers bring in is this
standard the compliance. Currently there are two main implementations of
the web services standards (JAX and .NET). 

If the hub will be rewritten in one of the new language programming,
Java for example, the frame data structure will be rewritten in XML
(XSchema for example) and the servers libraries updated to comply with
web services standards then CGSI will do the same stuff that it does
right now, but it will be more powerful (better multimodal interaction
support, multilanguage support through UNICODE, real functionality over
the Internet) and more flexible because it will use widely available
standards.

cristi

Re: [Communicator-user] GCSI and web services ? What do you think ?

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

   It occurred to me and I'm sure I'm not the only one, that the design of
   GCSI will make it a good candidate to a Web Service based infrastructure
   with some changes perhaps.

   Today if somebody would like to build a GSCI based dialogue system,
   he/she needs to download the infrastructure, compile it, try to put
   together a collection of servers and finally write a HUB program that
   will integrate them into a workable dialogue system. Getting all the
   necessary servers could be a real pain not mention making them run under
   one's operating systems. 

   With the increase growing of Internet bandwidth and with the increasing
   popularity of web based services based on (JAX or .NET), GCSI compliant
   servers could be made available online by various developing parties.
   The advantage is that they would be upgraded and maintained permanently.

The GCSI isn't necessarily compliant with any of these emerging
protocols (or previous ones like CORBA, SOAP, RMI, etc.), but I still
think it counts as a network service. 

After all, you don't need to be running your components locally; you
can set up your Hub to contact them anywhere. I can run a Hub here at
MITRE which contacts one of your servers at Sheffield, and except for
latency and firewall issues (which you'll encounter with any Web
service), everything will still work. If someone wanted to start a
cottage industry running GCSI-compliant servers 24/7, I don't think
there's anything to prevent them from doing so right now; the "parser
server in Kansas" model is certainly something we originally aimed to
support. 

   Tomorrow maybe, in order to build a GCSI based dialogue system, one
   would only need to download and compile the HUB and start writing a HUB
   program that will integrate various GCSI servers available as web
   services...

In other words, "today maybe". Am I missing something? If the issue is
standards compliance, I can certainly see your point, but if the issue
is (very-)remote access, I'm not sure I understand the problem.

Cheers,
Sam Bayer

[Communicator-user] GCSI and web services ? What do you think ?

[Cristi U. <c....@sh...>]

It occurred to me and I'm sure I'm not the only one, that the design of
GCSI will make it a good candidate to a Web Service based infrastructure
with some changes perhaps.

Today if somebody would like to build a GSCI based dialogue system,
he/she needs to download the infrastructure, compile it, try to put
together a collection of servers and finally write a HUB program that
will integrate them into a workable dialogue system. Getting all the
necessary servers could be a real pain not mention making them run under
one's operating systems. 

With the increase growing of Internet bandwidth and with the increasing
popularity of web based services based on (JAX or .NET), GCSI compliant
servers could be made available online by various developing parties.
The advantage is that they would be upgraded and maintained permanently.


Tomorrow maybe, in order to build a GCSI based dialogue system, one
would only need to download and compile the HUB and start writing a HUB
program that will integrate various GCSI servers available as web
services...

Among the components that are very suitable to be transformed into web
services I see the Speech Recognition, AUDIO???, Multimodal User
Interaction, Text to Speech, Natural Language Understanding. 

The focus will be perhaps on developing some customized GCSI servers for
one's business or task.

Is just an idea that I wanted to make it available instead of letting it
go away. :)) thanks for reading it.

cristi
=============================
"Everything should be made as simple as possible, but not simpler." 
 - Albert Einstein -

[Communicator-user] ADV: Harvest lots of Email addresses quickly

[eyou321 <ja...@em...>]

<HTML><HEAD>
<META content="text/html; charset=gb2312" http-equiv=Content-Type>
<META content="MSHTML 5.00.2614.3500" name=GENERATOR></HEAD>
<BODY bgColor=#ffccff>
<TABLE border=0 cellPadding=0 cellSpacing=0 width=475>
  <TBODY>
  <TR>
    <TD align=middle vAlign=top></TD></TR></TBODY></TABLE><BR>
<TABLE>
  <TBODY>
  <TR>
    <TD width="5%"></TD>
    <TD bgColor=#b8ecff borderColor=#0000ff width="90%"><FONT color=#ff0000 
      face="Arial Black" 
      size=6>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Want 
      To Get A Lot Of Email&nbsp;&nbsp; Addresses In A Very Short Time?</FONT> 
      <P><B><FONT color=#0000ff face=Arial size=4>Easy Email 
      Searcher</FONT><FONT color=#ff00ff face=Arial size=4>&nbsp; is&nbsp; 
      a&nbsp; powerful&nbsp; Email&nbsp; software&nbsp;&nbsp; that&nbsp; 
      harvests general Email lists from mail servers&nbsp;&nbsp; </FONT><FONT 
      color=#0000ff face=Arial size=4>Easy Email Searcher </FONT><FONT 
      color=#ff00ff face=Arial size=4>can get 100,000 Email</FONT></B> <FONT 
      color=#ff00ff face=Arial size=4><B>addresses directly from the Email 
      servers in only one hour!&nbsp;</B></FONT></P>
      <UL>
        <LI><FONT face=Arial size=2><B><FONT color=#0000ff>Easy Email 
        Searcher</FONT></B> is a 32 bit Windows Program for e-mail marketing. It 
        is intended for easy and convenient search large e-mail address lists 
        from mail servers. The program can be operated on Windows 95/98/ME/2000 
        and NT.</FONT> 
        <LI><FONT face=Arial size=2><B><FONT color=#0000ff>Easy Email 
        Searcher</FONT> </B>support multi-threads (up to 512 
        connections).</FONT> 
        <LI><FONT face=Arial size=2><B><FONT color=#0000ff>Easy Email 
        Searcher</FONT></B> has the ability&nbsp; to reconnect to the mail 
        server if the server has disconnected and continue the searching at the 
        point where it has been interrupted.</FONT> 
        <LI><FONT face=Arial size=2><B><FONT color=#0000ff>Easy Email 
        Searcher</FONT></B> has an ergonomic interface that is easy to set up 
        and simple to use.</FONT> </LI></UL>
      <P>¡¡<B><FONT color=#0000ff face=Arial>Easy Email Searcher is an email 
      address searcher and bulk e-mail sender. It can verify more than 5500 
      email addresses per minute at only 56Kbps speed. It even allows you send 
      email to valid email address while searching. You can save the searching 
      progress and load it to resume work at your convenience. All you need to 
      do is just input an email address, and press the "Search" 
      button.<BR></FONT></B></P>
      <P><B><FONT color=#ff0000 face=Arial size=4><I>Click The Following Link To 
      Download This Program:</I></FONT></B></P>
      <P><B><FONT color=#ff0000 face=Arial size=4><A 
      href="http://www.wldinfo.com/download/email/newees.zip">Download Site 
      1</A></FONT></B></P>
      <P><B><FONT color=#ff0000 face=Arial size=4><A 
      href="http://bestsoft.3322.org/onlinedown/newees.zip">Download Site 
      2</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      </FONT></B>¡¡<FONT size=2><FONT color=#0000a0 face=Arial 
      size=3><STRONG>If&nbsp; you can not download this program ,&nbsp; please 
      copy the following link into your URL , and then click " Enter" on your 
      Computer Keyboard.</STRONG></FONT></FONT></P>
      <P><FONT size=2><FONT color=#0000a0 face=Arial size=3><STRONG>Here is the 
      download links:</STRONG></FONT></P>
      <DIV>
      <P>http://www.wldinfo.com/download/email/newees.zip</P>
      <P>http://bestsoft.3322.org/onlinedown/newees.zip</P></FONT></DIV>
      <P></P></TD>
    <TD width="5%"></TD></TR>
  <TR>
    <TD width="5%"></TD>
    <TD bgColor=#0f95de width="90%"><FONT color=#ffffff 
      face="Verdana, Tahoma, Helvetica, SansSerif" 
      size=1><B>Disclaimer:</B><BR>We are strongly against continuously sending 
      unsolicited emails to those who do not wish to receive our special 
      mailings. We have attained the services of an independent 3rd party to 
      overlook list management and removal services. This is not unsolicited 
      email. If you do not wish to receive further mailings, please click this 
      link <A href=" http://www.autoemailremoval.com/cgi-bin/remove.pl " 
      target=_blank><FONT 
      color=#fdd32a><B>http://www.autoemailremoval.com/cgi-bin/remove.pl 
      </B></FONT></A>. Auto Email Removal Company. Ref# 
      01222263545</FONT><B><FONT class=disclaimer color=#000080 
      face=Arial><BR>This message is a commercial advertisement. It is compliant 
      with all federal and state laws regarding email messages including the 
      California Business and Professions Code. We have provided the subject 
      line "ADV" to provide you notification that this is a commercial 
      advertisement for persons over 18yrs old.</FONT></B></TD>
    <TD width="5%"></TD></TR></TBODY></TABLE>
<STYLE></STYLE>
<BR><BR><BR><BR><A href=""></A><BR><BR><BR><BR><BR><A 
href=""></A><BR></BODY></HTML>

[Communicator-user] Announcement: Galaxy Communicator HTK speech recognizer server

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

Hello everybody,

I have written a HTK (http://htk.eng.camac.uk) speech recognizer server for 
the Galaxy Communicator (http://communicator.sourceforge.net) - simple, but 
working and getting more and more flexible over time.

If anybody is interested in it, please e-mail me.

Regards -

Peter

-- 
*-) Dr. Peter Gober 
*-) FOKUS - Fraunhofer Institute for Open Communication Systems
*-) Kaiserin-Augusta-Allee 31
*-) 10589 Berlin, Germany 
*-) phone: +49 30 3463-7347
*-) email: go...@fo...

[Communicator-user] CMU Open Source Spoken Dialog Toolkit

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

			A N N O U N C I N G
				the
			  Carnegie Mellon
			    Open Source
		  Communicator Spoken Dialog Toolkit

We are pleased to announce the initial release of the Open Source
Communicator Spoken Dialog Toolkit (CSDTk). The Toolkit contains all
necessary components for building and deploying advanced spoken
language dialog systems, for both desktop and telephony
applications. The system is freely available for download at
http://www.speech.cs.cmu.edu/Communicator/ You can try out the
telephone-based Travel Planning system at +1 877 CMU-PLAN (268-7526).

The Carnegie Mellon Communicator Toolkit is based on the CMU
Communicator, a top-performing advanced dialog system developed as
part of the DARPA Communicator program. It is distributed with a
working implementation for a Travel Planning domain. CSDTk is built
on top of the open source Galaxy Communicator Software Infrastructure.

As distributed, the CSDTk operates in desktop mode. With the addition
of suitable hardware it can be connected to, and used over, the
telephone system.

The CSDTk incorporates the following major components:

- Sphinx II decoder(*), with automatic endpointing and barge-in
management. Sphinx is a speaker-independent, large-vocabulary
recognizer. The distribution includes acoustic, lexical and language
models for the Travel Planning domain.

- Phoenix semantic parser(*). With Travel Planning semantic grammar.

- Helios post-parser, including understanding confidence management.

- AGENDA Dialog Engine, including handler objects for Travel Planning.

- DateTime understanding module

- Travel back-end, including live access to airline and hotel
information for about 500 destinations world-wide.

- Rosetta language generation module, including the CMU Stochastic
Generation Engine.

- Festival(*) text-to-speech synthesizer, with Travel Planning voice database.

The systems in modules marked (*) are already available as separate
distributions. However, the Toolkit distribution includes versions
with interfaces specifically designed for the Toolkit.

Note that in addition to the CSDTk software you will need to install Perl
and a database server, such as MySQL. The initial distribution is for
Windows.

For information about the CSDTk, please contact Yitao Sun
(yi...@cs...). For general information about the Carnegie Mellon
Communicator project, please contact Alex Rudnicky (ai...@cs...).

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

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

[Apologies if you get this message more than once. We'll clean up the
mailing list overlap shortly.]

All - 

We are especially pleased and relieved to announce the release of
Galaxy Communicator version 3.3. 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. We would also like to
remind you that the first release of the Open Source Toolkit (OSTK),
version 20020125, is available.

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 

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 

Re: [Communicator-user] Communicator and VoiceXML?

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

>
> The state issue thus becomes a bit of a red herring: in reality no one
> really tries to explicitly enumerate all possible states for a system
> (which is in fact what you would have to do if you code directly in vxml);
> they write systems that (hopefully) are capable of generating all
necessary
> states. To tie this back to Communicator: most sites, whether explicitly
or
> implicitly, tried to develop some "theory" of state generation that would
> do this in a reasonably efficient manner. Notions like "mixed-initiative",
> I think really had to do with the problem of accommodating otherwise
> unanticipatable dialog states.
>

I do agree with this. Not even the so called "state based" dialog systems
attempt at enumerating all the possible states, and that includes also the
commercial - "mostly" system initiative apps - developed by SpeechWorks and
its partners. We tend to use the expression "state-based" for those dialog
systems whose strategy can be depicted with a graph with blobs and arcs, but
we tend to forget that there are conditions on those arcs that can be pretty
complex and that can refer to global variables - and this could be done, in
principle, also in voiceXML (although I agree that nobody in their right
mind would build a Communicator mixed initiative system in pure voiceXML).
So the states in the "state-based" system are general "clusters of states"
with the clustering function arbitrarily complex. If the complexity of those
clustering function is high, it becomers rather impractical representing the
dialog with blobs and arcs. On the other hand we at SpeechWorks have learned
the importance (for the goal of a task completion rate close to 100%) of a
finely tuned UI that often requires specific assignment of prompts and
grammar in specific situations in the interaction. And that generally is
easier to do if you have a "state-based" dialog manager where you can
control directly "every state" of the interaction. I guess this is one of
the many reasons that makes it hard to build a general theory of dialog
management that would satisfy everybody - i.e. the necessity of generating
(or clustering) states at a high level and the opposite necessity of
tailoring the UI to each individual state.

As far as the voiceXML dicussion is concerned, as Bob explained, we can look
at voiceXML *only* as the protocol used by the application server to invoke
ASR and TTS. The dialog is managed at the server side, and the dailog
manager could be state based as well  as anything else - as long as a
voiceXML document could be generated at each turn describing which grammar
(or language model) to activate and which prompt to play. Under that limited
use, voiceXML can be used within the Galaxy architecture with, in my
opinion, at least a couple of advantages: 1. buzz-word compliancy 2. easy
(but not completely transparent yet...) porting to different telephony
platforms as long as they are voiceXML compliant.

Roberto

Re: [Communicator-user] Communicator and VoiceXML?

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

   Go through the following exercise.
   Why do we have HTML? 
   Most people hate it.  
   We are all expert programmers. 
   You could just use cgi scripts to generate everything.
   In practice, if you are a good programmer/developer/researcher 
   and you want to write a web service 80% of your
   code is generated from cgi scripts.  
   So why is HTML there and still so widely used?
   1. non-experts can generate web pages/services quickly without
      knowing much about programming
   2. there are libraries and editors that hide all the uglyness  
      of HTML and provide modular components.
   (3. obviously it is the standard...) 

   That is also the answer for VoiceXML. 

   Some common misconceptions about VoiceXML that researchers have:
   1. You can't do mixed initiative with VoiceXML (WRONG!)
   2. You have to fully enumerate all possible states of your
      dialogue manager in VoiceXML (WRONG!)
   Get a high-school student to play a bit with VoiceXML. 
   You'd be suprised to see that he/she can do with VoiceXML 
   many of the things you can do in the research lab. 

Well, I suppose you could make the analogy between HTML and
VoiceXML. Except that VoiceXML isn't a markup language, really; it's
code in disguise. And as a programming language, it's really, really
badly designed. It makes all sorts of assumptions about how people
should build dialogue systems, which seem to have accreted through a
gradual process of "whatever people need in the next three months to
sell a telephone-based voice interaction product". Its extensibility,
as far as I can tell, is poor at best. And simply from looking at the
specification, I can't imagine how people could manage to write easily
maintainable code in it.

Sure, throw high school students at it. They've got (a) time to burn,
and (b) high tolerance for pain, and (c) little appreciation for good
design. I'm sure they can work miracles. We could also work miracles
with punch cards, but who in their right mind would do that today? 

If someone wants to stand up a Communicator-compliant VoiceXML
component, more power to them, and bless them for being willing to
tolerate it. As a dialogue researcher, however, I'm convinced that
it's not just lacking the basic infrastructure to do real exploration
of advanced dialogue capabilities, it's actually hostile to it. I
think that every dialogue researcher should certainly read the
VoiceXML specification and understand what's there. But researchers
shouldn't be the ones writing tools and libraries against a standard
as badly designed as this; it impedes our work, and frankly, we're not
rewarded well enough for the torture. 

Don't get me wrong; I like standards. I think they're a great idea. I
think we'd be toast without them. But it's a waste of my time to try
to conform to a badly designed, limiting standard, and I think
VoiceXML is a particularly bad standard. The SALT Forum specification,
on the other hand, makes a great deal more sense, and leaves the
appropriate room where the room is needed. Alex suggested that what
he's really using VoiceXML for is a uniform interface for speech in
and speech out over telephony; from what I've seen of SALT so far, it
does that far better than VoiceXML, and doesn't get in the way of real
dialogue development. The problem with SALT is that there's no public
version of it yet, and it won't be submitted to a standards
organization until later this year. It's a shame they've chosen to
work in private.

Cheers,
Sam

Re: [Communicator-user] Communicator and VoiceXML?

[Alexandros P. <po...@re...>]

Good or bad, just being a standard makes VoiceXML very valuable.
You both point this out.

However, I think that you both of you miss some other 
important points about VoiceXML.

Go through the following exercise.
Why do we have HTML? 
Most people hate it.  
We are all expert programmers. 
You could just use cgi scripts to generate everything.
In practice, if you are a good programmer/developer/researcher 
and you want to write a web service 80% of your
code is generated from cgi scripts.  
So why is HTML there and still so widely used?
1. non-experts can generate web pages/services quickly without
   knowing much about programming
2. there are libraries and editors that hide all the uglyness  
   of HTML and provide modular components.
(3. obviously it is the standard...) 

That is also the answer for VoiceXML. 

Some common misconceptions about VoiceXML that researchers have:
1. You can't do mixed initiative with VoiceXML (WRONG!)
2. You have to fully enumerate all possible states of your
   dialogue manager in VoiceXML (WRONG!)
Get a high-school student to play a bit with VoiceXML. 
You'd be suprised to see that he/she can do with VoiceXML 
many of the things you can do in the research lab. 

VoiceXML (and any other standard for that reason) is a blessing
for the ASR/dialogue systems field. I don't want to go
through the network economics of standards or spent 2-3
paragraphs discussing the stories of the adoption of
the FAX machine and the web.

I suggest that we researchers should spent some time to really
learn and evaluate VoiceXML. Figure out how our innovations can be
built into the standard without making it bulky. And then spent 
some more time building tools and libraries around the standard.

the other alex

ps BTW the main reason that VoiceXML is not used in high-density 
   applications in the field is EFFICIENCY (which you don't 
   touch on). 


>I agree with Bob's points.
>
>It's indeed quite reasonable to think of VoiceXML as simply an interface 
>standard that provides a uniform interface to speech decoding/encoding and 
>telephony services. I believe this is the de facto use for it in industry. 
>On a more local scale, this is what the students in our Dialog Systems 
>Design course (taught by Alan Black and myself) end up doing: apart from 
>stuff like the prologue, all vxml pages are generated through cgi scripts, 
>where all the real work of running the dialog gets done.
>
>The confusion, unless I missed something important, is that VoiceXML was 
>originally presented as a scheme for authoring dialog. You can certainly do 
>that but it really doesn't seem to make much sense for anything but the 
>most trivial systems. Practitioners have realized this. [But there may be 
>someone around here who can speak more authoritatively to the history of 
>the idea.]
>
>The state issue thus becomes a bit of a red herring: in reality no one 
>really tries to explicitly enumerate all possible states for a system 
>(which is in fact what you would have to do if you code directly in vxml); 
>they write systems that (hopefully) are capable of generating all necessary 
>states. To tie this back to Communicator: most sites, whether explicitly or 
>implicitly, tried to develop some "theory" of state generation that would 
>do this in a reasonably efficient manner. Notions like "mixed-initiative", 
>I think really had to do with the problem of accommodating otherwise 
>unanticipatable dialog states.
>
>Alex

Re: [Communicator-user] Communicator and VoiceXML?

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

I agree with Bob's points.

It's indeed quite reasonable to think of VoiceXML as simply an interface 
standard that provides a uniform interface to speech decoding/encoding and 
telephony services. I believe this is the de facto use for it in industry. 
On a more local scale, this is what the students in our Dialog Systems 
Design course (taught by Alan Black and myself) end up doing: apart from 
stuff like the prologue, all vxml pages are generated through cgi scripts, 
where all the real work of running the dialog gets done.

The confusion, unless I missed something important, is that VoiceXML was 
originally presented as a scheme for authoring dialog. You can certainly do 
that but it really doesn't seem to make much sense for anything but the 
most trivial systems. Practitioners have realized this. [But there may be 
someone around here who can speak more authoritatively to the history of 
the idea.]

The state issue thus becomes a bit of a red herring: in reality no one 
really tries to explicitly enumerate all possible states for a system 
(which is in fact what you would have to do if you code directly in vxml); 
they write systems that (hopefully) are capable of generating all necessary 
states. To tie this back to Communicator: most sites, whether explicitly or 
implicitly, tried to develop some "theory" of state generation that would 
do this in a reasonably efficient manner. Notions like "mixed-initiative", 
I think really had to do with the problem of accommodating otherwise 
unanticipatable dialog states.

Alex



At 12:03 PM 2/13/2002 -0500, Bob Carpenter wrote:
>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.

Re: [Communicator-user] Communicator and VoiceXML?

[Dave S. <sta...@bb...>]

Bob Carpenter wrote:
> 
> Two responses in one:
> 
> > from: Dave Stallard
> > Exactly.  In *theory*, you could develop a Communicator system using a
> > state machine formalism, but in practice the number of states and links
> > becomes prohibitive.  MIT had a paper at an ACL Conversational Systems
> > workshop
> 
> Does anyone have an exact reference to this?

Seneff S., and Polifroni, J. (2000) Dialogue Management in the Mercury
Flight Reservation System. ANLP Conversational Systems Workshop.

> If by a "Communicator system", you mean a system that takes
> customer calls to reserve airline flights, then you can
> also use a state machine in practice.  In fact, we have.
> With a very high task completion rate, I might add.
> But our systems probably wouldn't qualify as "communicator systems".

As I recall, at one time you guys were supposed to serve as a "pacing
horse" for the program, but that fell through somehow.

> You could argue that our reservations systems weren't "interesting"
> from a research point of view, and I'd agree with one caveat.
> They demonstrate what you can do robustly with today's technology
> with a high task completion rate.  From an engineering standpoint,
> no other technology has been demonstrated to work with even
> close to the same accuracy and task completion rates as our
> system-initiative, heavily hand-tailored, human voice talent
> prompted, state-based systems.  

I agree totally.  I'm not sure when, if ever, mixed-initiative systems
will pan out in terms of better task completion and user satisfaction
than system-initiative ones.  The motivation for many people working on
the problem is the pure existential goal of "talking to a machine".  
Who knows if that ultimately can be achieved, and if people will
actually want to do it if it is. 

BTW, what are your task-completion rates?  Communicator was topping out
at 80-90%.  

    Dave

Re: [Communicator-user] Communicator and VoiceXML?

[Dave S. <sta...@bb...>]

"Bradford W. Miller" wrote:
> 
> Turing machines, however, are a bear to program. What's far more important
> than simple theoretical computational power is having the appropriate
> expressive power, i.e., the right abstraction. Attempting to impose the
> right abstraction on a state machine is probably not the most efficient use
> of resources, just as I would not want to try to write the X window system
> in PROLOG (which is also Turing equivalent to more or less everything else),
> let alone use it once I was done.
> 
> Having the right architecture and abstraction makes it easier to envision
> and create the right solutions. I think the community is still searching for
> the right thing, but (in solid agreement with Alex (for a change! :-)) I'm
> pretty sure it isn't state machines.

Exactly.  In *theory*, you could develop a Communicator system using a
state machine formalism, but in practice the number of states and links
becomes prohibitive.  MIT had a paper at an ACL Conversational Systems
workshop a couple of years ago that illustrated this quite well.  We,
like CMU, started out early on with a state network, but quickly gave it
up in favor of a more flexible control scheme, as did MIT and U.
Colorado. 

I agree the community is still searching.  I think a standardized dialog
management formalism for Communicator-level systems is years away and at
this stage of development, that's fine.   Everyone that I know designed
their own, and (of course) thinks that theirs is the best.  I know I do
;)

   Dave

Re: [Communicator-user] Communicator and VoiceXML?

[Bradford W. M. <Bra...@mo...>]

Turing machines, however, are a bear to program. What's far more important
than simple theoretical computational power is having the appropriate
expressive power, i.e., the right abstraction. Attempting to impose the
right abstraction on a state machine is probably not the most efficient use
of resources, just as I would not want to try to write the X window system
in PROLOG (which is also Turing equivalent to more or less everything else),
let alone use it once I was done.

Having the right architecture and abstraction makes it easier to envision
and create the right solutions. I think the community is still searching for
the right thing, but (in solid agreement with Alex (for a change! :-)) I'm
pretty sure it isn't state machines.
-- 
Bradford W. Miller

Distinguished Member of Technical Staff
Symbolic and Distributed Artificial Intelligence
Intelligent Systems Lab; Human Interface Labs

Motorola Laboratories
7700 W. Parmer Lane, Mail Drop PL11
Austin TX 78729, USA

(512) 996-6851 (v), (512) 996-7320 (f) 877...@sk...
Bra...@mo...

> From: "Bob Carpenter"<bob...@sp...>
> Date: Wed, 13 Feb 2002 12:03:47 -0500
> To: <com...@li...>
> Subject: [Communicator-user] Communicator and VoiceXML?
> 
> and (3) states + memory = Turing machine, so I'd
> contend that "state-based" systems impose *no* limitations.

Re: [Communicator-user] Communicator and VoiceXML?

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

   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. 

Sam