Re: TCL and Related Speech Server questions

["TV. Raman" <raman@xxxxxxxxxxx>]

In UNIX there is no difference between sockets and stdin/stdout
as far as I/O  is concerned, *everything* is a  io descriptor.

Take a look at the chapter in Beautiful Code.
-- 

-- 


On 10/11/13, Tim Cross <tcross@xxxxxxxxxxx> wrote:
> Have a look at some of the scripts in the serves directory. There are a
> number of examples of things people have done with speech servers. For
> example, there is a basic server which you can run on one machine and have
> emacspeak use it from a different machine. One model I've used in the past
> was to have a small netbook running an emacspeak speech server and then
> running emacspeak on a Unix workstation where the speech is sent to the
> speech server running on my netbook. The benefit of this was that it made it
> easy for me to run emacspeak in a lab environment where I didn't know which
> terminal I would have access to. I've even used it where the lab was windows
> based, where I would ssh into a Linux server and run emacs with emacspeak
> and have the speech on my little netbook. Of course, how well this all works
> depends a lot on the infrastructure - how fast the LAN and WLAN are, what
> firewalls might be in place etc.
>
> Also in the server directory are some example scripts for running the speech
> server over ssh. I've used this a lot when I need to connect back to my work
> desktop from home, but want the speech sent to my local desktop.
>
> My experience, in general, is that the existing speech server architecture
> is capable of doing petty much whatever you need. It is actually very simple
> in design. The initial server script (the one called by emacs/emacspeak)
> takes the commands and then does whatever you want with them. This can
> include sending them to a server, either locally or remotely, tunnelling
> them through ssh or whatever. At the end of the day, it is just a script
> which accepts input on stdin. What it then does with that output is whatever
> you want.
>
> The biggest hurdle to using servers, ssh etc is usually in the initial
> setup. As environments differ widely, it is very difficult to have a one
> size fits all solution.Once you start brining in ports, networks, hostnames,
> firewalls, latency etc into the mix, things get compacted very quickly. For
> example, when using ssh to tunnel the speech from a remote host to your
> local desktop or laptop, you might have to think about how to handle dynamic
> IP addresses and hostnames, how to manage ssh keys and pass phrases
> securely, opening up firewall ports etc.
>
> So, the short answer to your question is that really, there is nothing which
> needs to be changed with the speech server architecture to handle either
> other languages or to handle servers. Tcl has support for sockets and even
> if it doesn't you can use any language you like to implement a speech server
> - all it has to do is read from stdin. The beauty of the current
> architecture is that it is simple.
>
> Tim
>
> --
> Tim Cross
> IT Security Manager, Information Technology
> University of New England
> Armidale N.Sl.W. 2350
>
> Email: tcross@xxxxxxxxxxx
> Phone: +61 2 6773 3210
> Mobile: +61 428 212 217
>
> On 12/10/2013, at 8:37 AM, Haden Pike <haden.pike@xxxxxxxxxxx> wrote:
>
>> Has there been any serious thought to rewriting the protocol to make it
>> easier on other languages?  For instance, writing to a socket instead of
>> STDIN.  That's off the top of my head, so there may be problems with that
>> approach that haven't occurred to me yet.
>> Haden
>>
>> On 10/9/2013 11:46 AM, T. V. Raman wrote:
>>> Good question.  The choice of TCL  is mostly historical:  in
>>> 1995, there were three languages that were approximately equal in
>>> popularity, perl, python and tcl.
>>>
>>> TCL  had one advantage over perl and python; in 1995, it was a
>>> lot easier to bind TCL  to a native C library -- and I needed
>>> that to integrate support for the software DecTalk.
>>>
>>> 2. In 1995, TCL and Python had an advantage over perl -- and this
>>> is still true -- both languages trivially expose a
>>> read-eval-print loop -- so you  can essentially write a server script in
>>> those languages where each  server command is just a function,
>>> and the client e.g. emacspeak, can launch the script  and write
>>> to stdin (or later over a socket) to send commands to the server.
>>>
>>> Fast Forward to 2013:
>>>
>>> If I started fresh today, I would probably write it in Python --
>>> given that TCL  development has slowed down.  That said, TCL is
>>> still a good option because it is well supported in general.
>>>
>>> Note that because of the initial servers having been written in
>>> TCL, emacspeak writes to the server assuming it's talking to TCL,
>>> so the python or Java server script has to do a bit more work.
>>>
>>> If you want to study this further, look in module dtk-interp.el
>>> --- if it ever becomes necessary, one could write an alternative
>>> implementation of that module that makes it slightly easier on a
>>> python server
>>>
>>> Haden Pike writes:
>>>  > Hi all,
>>>  >
>>>  > I got into a discussion about Emacs and Emacspeak with a sighted
>>>  > classmate who saw me using AucTeX to read my Calculus assignment. She
>>>  > asked me later why the speech servers use TCL.  I didn't know and my
>>>  > best guess was that it was the best option at the time.  Is this the
>>>  > case, or are there advantages I'm not aware of?
>>>  >
>>>  > Thinking about it later, I was curious if TCL should still be used
>>> when
>>>  > writing a new speech server, or whether something like the mac server
>>>  > should be written where possible?
>>>  > Haden
>>>  >
>>>  >
>>>  >
>>> -----------------------------------------------------------------------------
>>>  > To unsubscribe from the emacspeak list or change your address on the
>>>  > emacspeak list send mail to "emacspeak-request@xxxxxxxxxxx" with a
>>>  > subject of "unsubscribe" or "help".
>>>
>>
>> -----------------------------------------------------------------------------
>> To unsubscribe from the emacspeak list or change your address on the
>> emacspeak list send mail to "emacspeak-request@xxxxxxxxxxx" with a
>> subject of "unsubscribe" or "help".
>>
>
>

-----------------------------------------------------------------------------
To unsubscribe from the emacspeak list or change your address on the
emacspeak list send mail to "emacspeak-request@xxxxxxxxxxx" with a
subject of "unsubscribe" or "help".