.local config files

[Francis J. Lacoste]

On Sun, Sep 23, 2001 at 01:42:08PM +0200, Joost van Baal wrote:
> > 3) There are no way to customize only one parameter while taking automatically
> >    the rest of the configuration. For example, after an update, the new
> >    reports won't be automatically added to the customized report.
> > 
> >    Personnally, I think that having all the report's customization in one
> >    file is easier to grasp for the user then an indirected customization 
> >    in several files. It gives less granularity but I think the
> >    tradeoff is good. Running lr_config after an update could be a way to
> >    see that there are new repots available and add it to the customized
> >    report.
> 
> Hmm...  I'm not really sure about this.  Of course, the time we'd have
> to spent on coding the functionality is also to be taken into account :)
> (Ideally, lr_config would _read_ local configurations before starting
> to write a new local config file.)

The available reports and parameters aren't found in the configuration files,
but queried from the Lire API to the report specification framework. So
lr_config will allways be able to know all available reports.

> 
> One could argue that we should get rid of .../etc/lire/defaults.local
> _also_, to offer a consistent configutation framework.  I'm not sure
> about this neither, however...


etc/lire/defaults is a shell script. Having a defaults.local file in that
case is really convenient.

> 
> > 4) I don't know if there is a need to modify global parameters on a 
> >    superservice level. (Like to modify INCLUDE_IMAGES only in a specific
> >    supservice) If this is the case, we could add sourcing of
> >    <sysconfdir>/lire/defaults.<superservice>  or 
> >    <sysconfdir>/lire/<superservice>/defaults.local for backward compatibility.
> 
> I agree, we don't need this.  It's too baroque.
> 
> BTW, do you feel like upgrading lr_config to the current configuration
> files?  I believe that should be done before we can ship.
> 

I you allow me to do it in perl, no problem ;-). Seriously, I think perl
would be the easiest way to have access to all available reports and 
parameters using the API.

-- 
Francis J. Lacoste
francis at Contre.COM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.logreport.org/pipermail/development/attachments/20010923/61348b20/attachment.bin