Current Roadmap

[Trevor Saunders]

Hi,

On Tue, Aug 10, 2010 at 06:47:26PM +0200, Tomas Cerha wrote:
> Dne 10.8.2010 16:47, Trevor Saunders napsal(a):
> >>     * Rework of the settings mechanism to use DConf/GSettings
> > 
> > I'm not sure this is a very good idea.  The big thing that I think we 
> > *need* to
> > do settings wise is get rid of the AddModule configuration option in
> > speechd.conf.  In practice this seems to be the only option that people 
> > need to
> > change, otherwise most clients set everything else themself anyway to what 
> > they
> > want.  I have some ideas how we can get rid of the AddModule option.  I also
> > think configuration code should be auto generated from a description of the
> > file, but I don't think that's as urgent.
> 
> Yes, I think our concerns were quite similar.  Module configuration should 
> definitely
> not be necessary.  Speech Dispatcher should be able to discover available 
> modules
> automatically.  It should be quite simple for modules from the Speech 
> Dispatcher source
> tree.  All known modules would be on by default and Speech Dispatcher would 
> only need to
> handle errors during loading these modules properly (not report these errors 
> as fatal,
> log them consistently, etc).  Some configuration would only be necessary for 
> "out of the
> tree" modules (including user defined generic modules).  Better than having 
> directives
> in the main config file might be scanning configuration directory/directories 
> for per
> module files.

Heres a few thoughts
* why do you have this notion of on / off for modules?
* when an out of tree module is installed possibly with a config file it should
 just be available.

Heres how I think we can do this.
we assume all modules in /usr/lib/speech-dispatcher/modules are usable, we deal
with the generic module by making links like espeak-generic -> generic.  The
configuration file for any module /usr/lib/speech-dispatcher/modules/<module> is
/etc/speech-dispatcher/modules/<module>.conf
Another thing we can optionally change at this point is that we can load 
modules when
needed, but lets not worry about that yet.  So with the current start all
modules approach what we do is we try to run every file in
/usr/lib/speech-dispatcher/modules/ then the only thing we have to do is make
sure that modules say generic modules that the system doesn't have binaries for
for example dtk-generic on a system without dtk exit with an error that the
system doesn't support them. Of course these errors shouldn't be fatal to the
server.

> Quite separate problem is getting rid of the dotconf library (I guess there 
> is no need
> to explain why...).  We thought about dconf in this context, but this must be 
> explored
> further.  As you noted above, it would not be of a great benefit in the 
> current
> situation, where clients mostly set everything for themselves according to 
> their
> configuration.  It would make more sense if the clients made use of Speech 
> Dispatcher's
> configuration better and the advantage would be a central client wide 
> configuration.
> That's a topic for a separate thread, however.

Personally I don't have much of an issue with dotconf as a library to parse
configuration files.  The issue I wanted to cleanup is that we have to provide a
reasonable amount of code to dotconf so it can do something with wha it parses,
and the module configuration file templates, are dependent on the same thing, so
what I wanted to do was get rid of a bunch of boiler plate, and some pretty
confusing macros with autogeneration of the code.
Other than the fact its pretty much gnome only I don't have much love for dconf,
but that's not really relavent.  I think if we don't want to go the dotconf and
autogeneration route yaml or something similar may be a reasonable option.

Trev

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