speechd-el "modularity"

[Pierre Lorenzon]

Hi,

I wonder if speechd-el is enough modular. Indeed I am trying to
implement a direct client to festival without using
speech-dispatcher. Ideally it would be sufficient to replace
the ssip driver by a "festival-driver" implementing the
suitable methods. However it seems that certain task like
speechd.text are dedicated back to the main speechd library. In
particular it seems that the speechd.text method is essentially
the speechd--send-text function which is not driver
specific. In my mind it should be. I know that speechd-el was a
speech-dispatcher client at the beginning and that the other
output modules like brltty came later. Anyway I suspect that
this architecture is mostly due to historical reasons.

Now I should explain why I am doing such things. I know that
speech-dispatcher is a very powerful tool. Anyway my opinion
speech-dispatcher is not useful for those who only have
festival as synthesis. Indeed festival has all abilities to do
what speech-dispatcher is doing provided one write a few lines
of scheme code. In particular with the recent alsa support in
festival it seems possible to implement a reasonable speech flu
scheduler.

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

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

Regards

Pierre