I'd never considered sending the speech to a Netbook. Great idea! Haden On 10/11/2013 6:39 PM, Tim Cross 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".
If you have questions about this archive or had problems using it, please send mail to:
priestdo@xxxxxxxxxxx No Soliciting!Emacspeak List Archive | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 | 2001 | 2000 | 1999 | 1998 | Pre 1998