[dev] default backends

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>> - 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.

But in practical terms, you are still requiring this.  Using the IMP  
backends file as an example, the default is useful to quickly try out  
the application.  But I would say that easily more than 50% of the  
people won't want to use the defaults as they move to production.  (As  
an aside, the default for IMP is broken right now for any RFC 3501  
compliant IMAP server since plaintext logins MUST be disabled by  
default).  So they are still going to need to go to the config file,  
copy over the file to local.php, and edit it.

> - To simplify configuration. If we have sane defaults 99% of the  
> admins won't change anything in any configuration file.

I agree with this, but this is only important on the initial install  
not an upgrade.

And I still maintain that, for something like backends.php in IMP, it  
is now MORE difficult to make configuration changes.  It is now at  
least a 3-step process to add an IMAP backend (create  
backends.local.php if not already existing; create entry; login to  
Horde as admin; activate server in config screen (which may require  
cut/paste into a terminal window)).  And it is at least a 2-step  
process to activate an IMAP backend that already exists - because  
going to the web config page, how am I supposed to know what "Advanced  
IMAP Server" means?  What server exactly am I activating?  It is  
necessary to login to the server and visually inspect the backends.php  
file.

You could obviously rewrite the config code to show more details in  
the config screen, but at that point you might as well just move the  
backends configuration into the config file anyway.

My alternative: I would like to see activation of the servers occur in  
the config file itself (e.g. what I committed to IMP a few days ago).

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

Since I'm the one complaining about the new layout, it is my  
responsibility to provide an alternative.  So here it is: I think it  
would be easily doable to maintain a database in each application  
(e.g. XML file) that tracks any config file changes.  An admin could  
then go to a page (or command-line script) that will list the options  
that need to be upgraded.  The previous version can be stored in the  
config file; it is not until the admin manually updates this version  
number that the installation is considered upgraded.

This doesn't have to be as intrusive as an application like Gallery,  
which doesn't let you upgrade AT ALL until you go through the upgrade  
script.

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

I'm all for an admin UI for prefs files.  Someone needs to write it though. :)

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

I agree with the fact that a fresh install of Horde should have  
reasonable defaults out of the box.

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

I've always been uncomfortable with having things in config files that  
shouldn't be changed - I've done it myself with various options in  
mime_drivers.php for example.  Although these non-changeable config  
items are generally just specific settings in that file, not the  
ENTIRE file, and are clearly marked.

michael

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