Design suggestion: The server just for synthesis

[Hynek Hanke]

On 12.11.2010 07:38, Michael Pozhidaev wrote:
> Yes, I am going to work on this API but with modifications required
> for client/server architecture.

Actually it's implementation as a text protocol has also been
defined already in a draft:

     
http://cvs.freebsoft.org/doc/tts-api-provider/tts-api-provider.html#Text-Protocol-TTS-API

There is also an existing server implementation in Python.

> As first step it is good idea to read it again and write comments what is an 
> appropriate things and what can cause
> problems.

Yes, both the API and its implementations are still in draft stage,
so improvements are very welcome.

> Yes, removing TTS modules from Speech Dispatcher can significantly reduce
> current complexity. Having TTS modules both in Speech Dispatcher and in
> new server we are discussing is something strange.

Completely agreed. Then that puts the thing into a new light
and is even more along the lines I was thinking about for
the future.

I don't actually think we are talking about some entirely new
server. It's much more about refactoring the existing Speech
Dispatcher technology into three pieces, re-using its knowledge,
its design etc.

So if we are to commit that this is the way forward for the Speech
Dispatcher project and part of the Free(b)Soft project, we need
to work together on finishing TTS API, setting up a roadmap, setting
up a technical specification and the work on its implementation
under the review of the existing project reviewers. That way would
guarantee that the work is towards the same goals and it is spent
in a useful way.

Best regards,
Hynek Hanke