[dev] default backends

[Michael M Slusarz]

Quoting Michael M Slusarz <slusarz at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Ronan SALMON <rsalmon at mbpgroup.com>:
>>
>>> Again, as an admin, I think that this is a bit too much. Removing  
>>> unneeded config makes our life easier.
>>
>> What is too much? Using the configuration UI?
>>
>>> *I* don't see the benefit of having to use the GUI to enabled a  
>>> backend that is already enabled in the backend files.
>>
>> You need to go to the UI anyway to create the configuration. I  
>> don't get your problem.
>>
>>> What happens if you have IMP as your auth application and modify  
>>> the backend files ? You can't login I guess, because you need to  
>>> use the GUI to enable the new backend and disable the older one.
>>
>> Read docs/INSTALL. Creating the initial configuration was never  
>> supported while authenticating through IMP.
>
> I agree with Ronan (see my other post).  Creating a new backend  
> entry in backends.php and THEN needing to go back and recreate the  
> conf.php file is much too complicated.  Especially when you are  
> adding backends at a time well after you have configured IMP.  IMHO,  
> adding an entry to backends.php should Just Work (TM).

Other thoughts:

- We should be loading *.local.php files from a centralized location,  
e.g. Horde::loadConfiguration().  *.local.php files are really no  
different than vhost files - in fact, we should probably combine the  
functionality so there is a single system to override config values.

I just made the mistake of copying a config file to a .local.php  
file... and my installation completely broke as I caused an infinite  
loading loop of the local.php file due to the include *.local.php in  
the file.  Like it or not, this is exactly what users are going to do.  
  So having 'includes' in the default config files is a bad idea.

- Why are we forcing changes to be in the *.local.php files anyway?   
This only makes sense if installing from git.  Most users will be  
directly editing the default files and this isn't a bad thing.  If we  
are concerned about changing/adding default values when upgrading, I  
don't believe this has really been a problem in the past.

Forcing changes to *.local.php instead of *.php just makes things that  
much more complicated.  I can't really think of another project that  
requires people to do this.  And it sort of defeats the whole purpose  
of storing the default "config" files in config/ in the first place.   
These new default files are instead hardcoded values and if users  
really aren't supposed to be touching them, they should be nowhere  
near the config/ directory.


FWIW, I have pushed code removing the conf.php setup in IMP and  
instead added a 'disabled' property directly to backends.php.   
Comments welcome/appreciated.

michael

-- 
___________________________________
Michael Slusarz [slusarz at horde.org]