Considering ConsoleKit and GSettings/DConf

[Trevor Saunders]

HI,

On Wed, Aug 11, 2010 at 05:14:00PM +0200, Hynek Hanke wrote:
> 
> Hello all,
> 
> I'm posting the reasons why some of us propose
> ConsoleKit and DConf for the 0.8 release. This is
> still open question, so I'll welcome comments.
> 
> * Why do we need ConsoleKit
> 
> Speech Dispatcher needs to obey the rules for nice
> behavior of user session daemons. Most important:
> 
>     1) Free resources when session is not active
>     2) Do not consume CPU when session is not active

personally I don't care about session integration, but if you want to add 
support for it that's fine.

> Speech Dispatcher is currently not sticking to these rules.
> With Pulse Audio, detaching when in inactive session is not
> so important, but with ALSA and other audio output methods,
> it's crucial since we block everyone else.

This shouldn't be a problem we shouldn't be taking exclusive locks on any of the
alsa files so others should still be able to use them.

> Consider the current audio fallback mechanism ,,pulse, alsa''.
> If for any reason (e.g. because early in the bootup process)
> this mechanism starts Dispatcher with ALSA, this breaks
> Pulse Audio output for any user on the system unless they kill
> that Speech Dispatcher. This is completely unnecessary.

agreed, as above I don't see why this is an issue, we shouldn't have an
exclusive lock on any of alsa, so pulse should be able to use alsa even if we
already have a connection open.

> (Audio fallback needed to be disabled for 0.7.1 as this is
> a real problem with BrlTTY.)
> 
> We also consume CPU unnecessarily. Speech Dispatcher will
> synthesize any incoming text regardless of whether the
> current session is active or not. That synthesis produces sound
> which will never be heard.

I don't see this as a big deal, I don't think we should even be being sent 
messages
if the session is inactive really.

> This is all also important for running Speech Dispatcher
> in the ``idle session'', as we discussed before, to enable
> reading startup messages, login etc.
> 
> Using ConsoleKit, Speech Dispatcher will always know,
> whether it operates in a session which is currently active.
> When the session is inactive, it will detach from resources
> (such as blocking audio) and will not waste CPU time
> for speech synthesis.
> 
> I've already tried some testing program communicating
> with Console Kit over DBUS and receiving signals on
> session activity, and I must say it seems easy. We will only
> need to figure out a way how to pass the signal to the modules,
> but that can be done analogous to other asynchronous commands
> which we already use (STOP).

another issue we'd have to deal with is since sd is network transparent what
exactly the importance of the session on the local machine is.  Take the
following example I have one sd server running on a server with the modules,
currently I am not logged into this machine, but am using the speech dispatcher
on the machine by pointing the screen reader on the local machine at it, and
getting the audio back with nas.  While designing  the enterprisey wonder that
is console kit / session integration they may have come up with a solution for
this sort of situation, but I've never looked.

> * Why do we need DConf/GSettings
> 
> 1) While text based configuration has its advantages for
> advanced users, it is a problem for less experienced users.
> It is very easy to make errors in syntax or in the content
> of the settings themselves (like there is no way to enforce
> enumeration values etc.).

there is a perfectly good way to deal with this, report the error and use the
default, then the user can fix it.

> 2) It is difficult to maintain an up-to-date configuration file
> on target users computers across different releases of
> Speech Dispatcher. Removal of old config file and installation
> of a new one is not trivial if settings should be maintained
> and typically must be done by the user by hand. If users do not
> update their config file when asked to, this often leads to
> problems.

yes, and that is there fault, and they will realize the problem and fix it.

> 3) Commentaries in text based config files are in English
> and not possible to localize.

No, I can't see a reason that they can't be localized.

> 4) Current DotConf settings implementation in Speech Dispatcher
> needs a lot of code, even though we simplified it by using
> macros which generate the code.

sure, this is why I proposed autogeneration of the code along with default
config files, this may also help with localization of config files.

> 5) It is not possible in text based configuration to get
> notification on configuration changes.

no, it is possible, see ssh / openttsd / other daemon, sending them SIGHUP will
cause them to re read the config file.

> 6) As Tomas pointed out, a more dynamic configuration
> mechanism will allow us to do very interesting things,
> like settings profiles, which can become a major improvement
> and simplification in the whole AT chain.

I think we can do this either way.  However I don't think this will work very
well or will be a good idea, however I could be convinced otherwise.  My issues
are that one it violates the principal of doing one thing well.  The big problem
however is that screen readers will still want to support other speech backends
which will mean they implement this themselves, and then we just end up with
this done in two places, which will be much worse than not having done it.

> Whether DConf is the right way to address these issues
> and whether it is acceptable for platforms other
> than Gnome must however be investigated.

Well, Personally I tend to believe non text based configuration is pretty evil,
and bad design, accept in extrem cases, in which case the text -> other and
other -> text transformations should be very simple.

Trev


> 
> Best regards,
> Hynek Hanke
> 
> 
> 
> 
> _______________________________________________
> Speechd mailing list
> Speechd at lists.freebsoft.org
> http://lists.freebsoft.org/mailman/listinfo/speechd