Considering ConsoleKit and GSettings/DConf

[Hynek Hanke]

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

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.

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.

(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.

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).

* 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.).

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.

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

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.

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

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.

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

Best regards,
Hynek Hanke