Speech Dispatcher roadmap discussion.

[Luke Yelavich]

CCing to the speechd list, and thanks for your feedback.

On Wed, Oct 08, 2014 at 08:02:35PM AEDT, Halim Sahin wrote:
> Hi,
> Am 08.10.2014 09:32, schrieb Luke Yelavich:
> >* Implement event-based main loops in the server and modules
> 
> Pros and cons?

Ok, I can think of a few pros, but cannot think of any cons. Someone feel free 
to chime in if you can think of any.
* Pro - It is non-blocking, which allows Speech Dispatcher to do other tasks 
even whilst it is waiting for client activity.
* Pro - Allows the possibility for timer based events, i.e if there are no 
clients connected, and the server waits for a defined and configurable period 
of time, it can perform an action, i.e shut itself down.
* Pro - Allows event prioritization, i.e if you want the servicing of currently 
connected clients to come first, that can be assigned a higher priority.
* Pro - Allows for the possibility of inotify based file monitoring if desired, 
which means the file descriptors are not constantly being polled, which means 
less system resource usage. It should be noted that inotify is linux specific, 
but other platforms do offer something similar. Since GLib would likely be 
doing the work, it will depend on support being implemented in GLib for the 
platform in question.

> >* Assess whether the SSIP protocol needs to be extended to better support 
> >available synthesizer features
> ok.
> 
> >* Assess DBus use for IPC between client and server
> 
> I see _no_ advantages to use d-bus at all.
> I don't think that a console screenreader like sbl or brltty should use
> d-bus to talk to speechd. This would only add more complexity to clients!

I personally agree with this, but it was on the original roadmap, so I decided 
to add it anyway. If enough evidence can be presented as to why we should use 
DBus, then I am willing to reconsider.

> >* SystemD/LoginD integration
> Ok In fact most distros are using unfortunately systemd.
> Please keep backward compatibility. Maybe other systems like **bsd* should
> be able to use speechd without having systemd running.

SystemD is Linux Specific, so any support for ConsoleKit/SystemD etc would be 
enabled at build time, and it will have to be modular, given the need to 
support different *nix flavours.

> >* Rework of the settings mechanism to use DConf/GSettings
> If you realy plan to change the settings stuff to gsettings, make sure that:
> 1. speechd can be configured without running complete Desktop like gnome.

That is certainly possible. Gsettings does have command-line tools to allow for 
this.

> 2. Settings should be accessible without installing a Desktop because many
> embedded systems don't have gnome installed. In that case speechd needs to
> be configured from plain textconsole.

What I had in mind was to refactor spd-conf to be a multi-ui configuration 
tool, in that it can provide a text UI on the console, and if desired, a GUI 
for graphical desktops. So given that approach, I am sure we can satisfy point 
2 that you raise.

> >* Separate compilation and distribution of modules
> 
> FULLACK.
> >* Consider refactoring client API code such that we only have one client API 
> >codebase to maintain, i.e python bindings wrapping the C library etc
> 
> My thought: maintain only c api and use something like ctypes to use it in
> python.

Given I am not strong in python, this is one option I always forget about. 
Indeed, using ctypes is an option, but perhaps we wrap it in a little python 
code to make it easier for developers such that they do not need to know how to 
use C types.

> >* Moving audio drivers from the modules to the server
> Hmm this will make things unstable for a long time. I am not sure if this is
> really a problem and it's only a problem in pulseaudio.

As I said, its not entirely pulseaudio specific. Even with libao or ALSA, you 
may want to have one Speech Dispatcher client coming out of one sound card, 
and, and another coming out of a second sound card, and both clients may wish 
to use the same speech synthesizer. Moving audio output management to the 
server would allow for this. This is something that would likely require a 
separate feature branch to be developed, and kept in sync with master, until it 
is stable enough to be merged.

> Since pulseaudio integration there is no easy way to get audio running in
> plain textconsole.
> This produces many problems for new users.
> Please give it a higher priority and let's try to find a working solution
> for it.

This issue, while affecting pulseaudio, also affects plain ALSA use as well. 
With distros now using session and seat management with Consolekit/LoginD, the 
problem has to do with permissions of various device nodes needed for hardware 
access, and yes even speakup falls into this category. As it stands now, it is 
possible to run Speech Dispatcher et al in your text console user session, and 
all should work. The problem arrises when you want an accessible text login. 
The reason why GUI login systems work is because the GUI login manager runs as 
its own user, and is treated like a logged in session, allowing for audio 
devices etc to work. What is needed is for a special session type to be added 
to ConsoleKit/LoginD. THis special session would be run as a separate user, but 
tat user would get access to audio, console etc whenever the active vt does not 
have a logged in user. In other words, you switch to a text console with a 
login, and this special session type is marked as the active session. As a 
result, all processes running under atht special session, i.e Speech Dispatcher 
and speechd-up, gets access to the audio device hardware and speakup device 
node, and allows the user to read the console at login.

> BTW.: loading all outputmodules should be reworked.
> In my opinion only installed sysths should be loded not all available output
> modules.

Agreed.

Thanks again for your feedback.

Luke