[dev] default backends

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at horde.org>:

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

Agreed.

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

Makes sense.

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

The reasons for this are:
- To simplify installation. Having admins going to each application's  
config/ directory and copying each and every .dist files is an  
uncecessary step.
- To simplify configuration. If we have sane defaults 99% of the  
admins won't change anything in any configuration file.
- To simplify upgrading. Upgrading required admins to basically do a  
3-way-merge between the old .dist file, the new .dist file, and the  
production .php file. For every single configuration file. For every  
upgrade. Now, they install the upgrade and be done, without losing any  
custom configuration. They only need to intervene if we change the  
structure of configuration files, which didn't happen in decades, or  
if we add a new configuration item that they want to change.
- Changing configurations like prefs through a UI is easier to  
implement. Instead of having to find an xml format and configuration  
code that maps the complexity of e.g. pref.php (which is much higher  
than the complexity of conf.php), a UI could simply allowing picking a  
preference (that we already know it exists) display a widget for it  
(that we already have implemented in Prefs_Ui) and save a different  
default value, or lock it. The result, that only contains the single  
change, can be saved in prefs.local.php.

Again: this is not about experienced administrators who have been  
managing Horde for years. This is for first time users who want to get  
Horde running in a few minutes. They can now unpack Horde, create  
Horde's conf.php file, go to the configuration screen, hit save (we  
can probably even shortcut this), and run the migration script. Done.

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

The point is that it doesn't require to do this at all. And I know at  
least one project off my head that did exactly this change in  
configuration: phpMyAdmin. You used to have to copy a .dist file to  
.php to get it running, a file that contained all possible  
configuration settings.
Recent versions ship with a reference configuration file, and anything  
that need to be changed from the defaults, including the initial setup  
with the connection credentials, is done through a configuration  
interface and saved in a configuration file addendum that only  
contains those custom settings.

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

This is indeed debatable, but I think it makes still sense to keep the  
defaults in config/, so that admins have a reference of the default  
settings.

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

I've reverted it for now, because it doesn't make sense to change this  
for a single configuration file. This need to be implemented  
consistently.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/