[dev] default backends

Fri Feb 18 08:55:40 UTC 2011

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

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

I still think that activating through the configuration screen is  
easier for the average admin, but since I seem to be in a clear  
minority here, I'm fine with making this a configuration switch in the  
backends.local.php files.

>> - 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 sounds like really overcomplicating things instead of making them easier.

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

At least we're prepared for that ;-)

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

That's a different story though and independent from the configuration  
file layout. But I agree that we shouldn't offer configuration for  
settings that really shouldn't be changed.

Jan.

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