Idea: extending SSIP protocol with CAPABILITIES command

[Hynek Hanke]

On 30.10.2010 10:08, Bohdan R. Rau wrote:
> Multi-language applications (like screenreaders) can perform particular
> actions, but speech module (specialized for particular language) does it
> better if this action is implemented.

Yes, exactly. Synthesizers (or modules) should report what
are their capabilities. Speech Dispatcher can have plugins
which can emulate some of the functionalities and report
extended capabilities up in the chain.  If even this is not
sufficient, the screen reader can attempt to hack around
the situation.

Also not, that in other situations, it is not possible or not
feasible to provide any emulation for the given capability
(e.g. unability to change voice rate), but it is still useful
for the screenreader/user to know about it.

The TTS API specification (which is of course still open
to improvements) already includes this capability. See:

http://cvs.freebsoft.org/doc/tts-api/tts-api.html#Speech-Synthesis-Driver-Discovery

It has also already been implemented in a text protocol
in a way very similar to what you propose:

http://cvs.freebsoft.org/doc/tts-api-provider/tts-api-provider.html#Driver-Discovery-_0028text-protocol_0029

If you like, it would be useful to improve these specifications and then
implement them in SSIP documentation (not everything will be the same
in SSIP of course, the set of capabilities to handle will be smaller). Once
we have the SSIP docs, we can start to implement it in the server and
modules (and eventually synthesizers -- eSpeak and 
festival-freebsoft-utils).

Best regards,
Hynek Hanke