rfc module autodetection patch set

[William Hubbs]

On Fri, Nov 19, 2010 at 02:29:38PM -0500, Trevor Saunders wrote:
> On Fri, Nov 19, 2010 at 03:09:28PM +0100, Tomas Cerha wrote:
> > Dne 18.11.2010 12:40, Trevor Saunders napsal(a):
> > > 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.
> > 
> > It may be nice for troubleshooting for example, so that you easily 
> > recognize SD modules
> > in ps and such.  I't probably not a strong argument, however.
> 
> fair point, I don't see any really good reason to get rid of it though.

As far as I know, the only reason for the sd_ prefix would be if there
is a possibility of another binary having the same name and overwriting
it.  I think we can get rid of the prefix since the modules are stored
in a private directory that is part of speech dispatcher.

> > > *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.
> > 
> > Sounds nice.  The only objection that comes to my mind is portability.  
> > What about file
> > systems, that don't support symlinks?  Why not discover just the available 
> > generic
> > configuration files?

In order to do this, you have to assume that all generic configuration
files will have a certain naming convention.  Ours in the package do,
but should we require this of all users who want to write generic
configuration files?

> > Also, what about detection whether a particular generic module is actually 
> > available?
> > The sd_generic binary is in place, the symlink is in place, the 
> > configuration file is in
> > place as well, but tha actual tts binary is not installed...  I think 
> > someone already
> > suggested adding an option to the generic module configuration, that would 
> > allow testing
> > for availability of the particular generic module (i.e. testing the 
> > availability of the
> > required tts binary).  SD would attempt to make this check for all 
> > discovered generic
> > module configurations (or symlinks if people prefer them).

Here is another thing to consider with symlinks.  If you want the
symlinks in the same directory as the module binary, only root can
create those symlinks, which means that a user can't set up his generic
module to be auto discovered.

I would vote for the opposite approach, namely not trying to
auto-discover the generic modules, but requiring the user to use the
AddModule directive if they want to use generic for anything.

> yes, this is a good point, but I think we already have to solve this
> problem to some extent because some modules like cicero can be inplace,
> and still not work, because they assume they can exec programs at run
> time or other things.  I think having such modules run a check that they
> can work at startup and exiting if not may be a good solution.

To me this is a topic for another thread.

William

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://lists.freebsoft.org/pipermail/speechd/attachments/20101119/f204539e/attachment-0001.pgp>