running speech-dispatcher-0.7.1 in system mode

[Halim Sahin]

Hi,
On Thu, Oct 07, 2010 at 11:14:28AM +0200, Hynek Hanke wrote:
> On 7.10.2010 10:11, Trevor Saunders wrote:
> > I'm curious why you are so opposed to speech dispatcher
> > running as a system service?
> >    
> 
> Security, no clear way to autospawn, not reachable via DBUS,

It doesn't need root privileges (under debian), 
BTW.: gdm runs as root under Gentoo :-(.A multi-seat environment is not
the typical setup where two users works at the same on the same machine.
Please make sure that common setups work before adding such special
cases.
Autospawn for servers is
nice to have but not essential because it does not recover crashed
modules, and the sever can be started through an init skript (s.
Debian).

Sd doesn't have dbus and btw.: the future will show if we can use a dbus
connection for an usefull usecase.
Having message priorities in sd is nice to have but I don#t know any
situation were this feature is used in orca (maybwe I am wrong here)?

> not compatible with PulseAudio, 

That is not a problem  in general. If the pa folks would care about
_special_ needs of a11y we wouldn't discus this user-session problem
almost every day. redesigning speechd speechd is only needed of that
audio playback issue.
Don't forget that a big distro like debian doesn't install pa in their
default setup.

So we need a working solution at least for those distros.

> problems with order of startup,

On which distro? I am now using speechd since three years and never
experienced problems in the startup process.


> dependency on distributions init scripts which often proved to
> be broken, 

I think these were due to packaging issues and I dont think that this is
a good reason for changning that.

> problems in multi-user environments.

Well let me describe how sbl handles settings per user and global ones.
Maybe this could be adapted to speechd as well :-).
It checks for changes in the active tty and loads the setting of the 
user who works on the current active console.
If that user doesn't have such settings, it uses system's global ones.

Implementing such features would be enough to have almost the same
features which is needed for user session integration.

> Anyway, as I proposed, I think we need to compile a list
> of pros and cons for both solutions and then refer to it
> in the documentation, so that packagers and users would
> be able to choose either. They will both stay supported.


Well, I see no advantage of running speechd in the user's session
because it produces a lot of overhead by handling login (in idle
session).
Having other ipc mech like dbus sould be optional and should not prvent
sd from running system-wide.
I suggest that _you_ from brailcom ask the pulse devs for adding a
previliged access to pulseaudio for special a11y talsks.
Using pulseaudio is the only reason why you are trying to do this
refactor which wouldn?'t improove anything for _users_.
Saying that the programs can be adapted needs description of a working
fix for sbl brltty or speechd-up.
This solution should also work to read a plain text-login.
Greetings
Halim