Idea: extending SSIP protocol with CAPABILITIES command

[Tomas Cerha]

Dne 1.11.2010 16:52, Andrei Kholodnyi napsal(a):
> On Mon, Nov 1, 2010 at 3:55 PM, Hynek Hanke <hanke at brailcom.org> wrote:
>> 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.
> 
> But not directly to the client application IMO.
> And this AFAIU Bogdan is proposing.
> 
>> Speech Dispatcher can have plugins
>> which can emulate some of the functionalities and report
>> extended capabilities up in the chain.
> 
> This would be a proper way, i.e. SPD reports the same capability for all 
> synths.
> I believe we have already discussed it taking punctuation as an example.
> SPD in this case shall provide the same look and feel
> for NONE, SOME, ALL regardless whether particular synth supports it or not

Yes, I think Andrei raised a valid point.  One of the main concerns of SD 
design was
providing a transparent interface which hides the details of the speech 
synthesizers
from the client applications.  This means that the client application should 
not be
required to care whether a particular synthesizer supports a particular 
feature.  It
should only inform SD what is the expected mode of operation and SD should do 
its best
to respect the requested mode (whatever that means in a particular situation).

So the capabilities protocol makes a lot of sense for communication between the 
server
and the modules, but it should not be necessary between the server and clients. 
 Unless
we have a good reason, I would not exhibit this protocol to clients.  If we 
have a good
reason, clients should at least not be expected to use it.

Best regards, Tomas