speechd-el "modularity"

[Milan Zamazal]

>>>>> "PL" == Pierre Lorenzon <devel at pollock-nageoire.net> writes:

    PL> However it seems that certain task like speechd.text are
    PL> dedicated back to the main speechd library. In particular it
    PL> seems that the speechd.text method is essentially the
    PL> speechd--send-text function which is not driver specific. 

I don't understand.  `speechd.text' indeed is a standard driver specific
method and you can redefine it to whatever you want in your driver.  In
speechd-ssip.el it calls speechd-say-text while in speechd-braille.el it
uses speechd-el Braille output mechanisms.  There is no direct
connection between `speechd.text' and particular drivers, it's just an
abstract (and in its base definition empty) output method.

The easiest way to start with alternative speech outputs in speechd-el
is to copy speechd-ssip.el file (SSIP driver implementation), use it as
an example of implementing a particular speech output driver and change
all the definitions inside it for your own driver.

    PL> The gain is that instead of two connections in the chain (and 2
    PL> servers, 2 clients) there is only one connection one server, one
    PL> client and hence the system will be more reactive.

As Tom?? has already remarked there is hardly any real gain to expect
but I can understand it may be fun to play with such things. :-)  If
nothing else it might make one to better appreciate all the work Speech
Dispatcher does for him :-) or maybe to find out some feature missing in
Speech Dispatcher.

    PL> So shall we plan to have more separation of the tasks in
    PL> speechd-el ?

I think the tasks are well separated.  The fact that speechd-el can talk
to both Speech Dispatcher and BrlTTY proves it.