Current Roadmap

[Tomas Cerha]

Dne 10.8.2010 21:49, Trevor Saunders napsal(a):
> On Tue, Aug 10, 2010 at 06:47:26PM +0200, Tomas Cerha wrote:
>> 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?

Yes, instead of "on by default" I should have written "always on", thus 
abandoning the
notion of on/off completely.  I just wasn't clear enough...

> * when an out of tree module is installed possibly with a config file it 
> should
>  just be available.

Yes.

> 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

Maybe just the presence of the conf file and its contents would link it to the 
generic
module, so the filesystem links might not be necessary.

> Another thing we can optionally change at this point is that we can load 
> modules when
> needed, but lets not worry about that yet.

Yes, but we must be able to discover which are available.  This is probably 
easiest done
by trying to start them, but we may consider other options as well.

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

Yes.

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

We definitely want to stay desktop neutral, which should be theoretically 
possible with
DConf/GSettings, but it needs to be investigated how this neutrality can be 
achieved
practically.

Best regatds, Tomas