speechd-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

rfc module autodetection patch set


From: Hynek Hanke
Subject: rfc module autodetection patch set
Date: Wed, 01 Dec 2010 15:12:36 +0100

On 18.11.2010 12:40, Trevor Saunders wrote:
> this patch set first cleans up the way we load modules a little by
> moving the actual initialization out of the dotconf call back.  Then it
> adds a very simple autodetection algorithm.  We simply assume everything
> in MODULEBINDIR is a module, and well if it isn't it should fail to
> initialize.

This sounds very good, thanks for the great work!

> There are some things that should be thought about some here.
> * currently modules file name starts with sd_xxxx do we have a good
>   reason for this when coming up with a name rom each file this code
>   simply adds three to the pointer to the string to skip the sd_ when
>   getting the name, which should be checked if we want to keep the sd_
>   prefix.

The motivation for using the sd_ prefix was to be able to
easily distinguish Speech Dispatcher module binaries in
active process listings in ps, top and such.

> * we still deal with all the module loading in
> speechd_load_configuration() is this where we want it to happen.

I would prefer to separate it. Please also look how this is related
to SIGHUP handling, which reloads configuration at runtime and
is also supposed to do the correct thing for modules and their
configurations.

SIGHUP is I think the only way to change (some parts of) configuration
without disconnecting the clients. (e.g. add a new module or change default
or module parameters) On one side, I think its usefulness on the desktop
is quite questionable, especially as most clients would automatically 
reconnect
on full server restart anyway. But perhaps in some network setups with 
multiple
remote clients, one would want to do configuration changes in the server 
without
disconnecting the clients.

> *it would be nice for autodetection to be able to work with the generic
> module to some degree, based on the way the current support works this
> is fairly easy if we can add links in MODULEBINDIR from say
> espeak-generic to the binary sd_generic that way the detection would try
> to exec sd_generic with the config file modules/espeak-generic.conf.

Symlinks are a nice solution. The generic modules should not be
handled as a special case in the server logic. There is nothing 
fundamentally
different about them except for their internal implementation details
and their restricted capabilities.

On platforms where symlinks are not possible, packagers can simply
supply wrapper scripts in MODULEBINDIR.

> *I keept the Addmodule directive so people could deal with configuring
> modules not in the MODULEBINDIR, and other nonstandard things.  It would
> be nice if a hand configured module with the same name as an
> autodetected one could override the autoditected value, instead of
> dupplicating it.

I agree.

Best regards,
Hynek Hanke




reply via email to

[Prev in Thread] Current Thread [Next in Thread]