[Accessibility] TTS API Provider implementation

[Hynek Hanke]

Hello,

Brailcom is now working on practical implementation of a server and
drivers which will provide the API we have designed on this mailing list
and will conform with the discussed requirements. Minor changes and
future development of the requirements and the API specifications are of
course still possible and expected, as well as later versions of the
specifications.

I've created a new project called TTS API Provider here
    http://www.freebsoft.org/tts-api-provider
including documentation draft of the basic design and
two variants of TTS API for use in Python and in a text
protocol.

There is a mailing list for the implementation, design discussions and
testing here
	http://lists.freebsoft.org/mailman/listinfo/tts-api
The API specifications should continue to be discussed on this mailing
list (accessibility at lists.freedesktop.org).

Our aim is now to create the basic infrastructure of TTS API Provider
(server core, communication layer, driver templates and libraries).
The plan is than to port the existing TTS functionality (emulations,
audion output, drivers with help of the original authors) from Speech
Dispatcher, KTTS and Gnome Speech to TTS API Provider.

Next major version of Speech Dispatcher will be based on TTS API
Provider. Until then, we will only be releasing minor bugfix and
contributions versions as was the recent 0.6.1. Speech Dispatchers only
(but very important task) will then be providing a high level interface,
multiplexing and prioritization of messages (both from one client and
from various clients) and possibly also braille output -- this will be
subject of further discussions.

We strongly believe applications must continue to interface Speech
Dispatcher (or KTTSD or Gnome Speech) instead of TTS API Provider. We
have left prioritization and multiplexing of messages out of scope for
TTS API because it does not really belong here, is not specific to
speech and we do not have clear agreement about it yet. TTS API Provider
is supposed to be interfaced by the higher level interfaces (Speech
Dispatcher etc.), also applications who only store audio but do not play
it (txt2wav converter) and very very specialized applications who are
authorized to take full control of the speech on the given system (but
this rules out accessibility). In other words, this is not an effort to
replace Speech Dispatcher (or the other speech systems) with something
lower-level and without prioritization. This issue which of the
higher-level technologies to use or how to make them cooperate instead
of conflict will require further discussions.

Any help with the implementation is very welcome. Please contact us
on the above mailing list or privately on hanke at brailcom.org .

With Regards,
Hynek Hanke