[dev] default backends

[Chuck Hagenbuch]

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

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Rui Carneiro <rui.carneiro at portugalmail.net>:
>>
>>> On Mon, Feb 14, 2011 at 10:50 PM, Ronan SALMON  
>>> <rsalmon at mbpgroup.com> wrote:
>>>>
>>>> Thanks for this example that clearly shows why the old way was not perfect
>>>>> and the new way is much better. After these changes, what you to is:
>>>>> 1. Update the Horde tree.
>>>>>
>>>>
>>>> I agree with Jan here. I find the *.local.php files really handy.
>>>> Especially when you will upgrade Horde and Horde apps, you'll  
>>>> automatically
>>>> get the new settings.
>>>
>>>
>>> This is not necessarily good .
>>>
>>> The following example might not be the best one, but here it goes:
>>> - The current default for $_prefs['initial_application'] is 'horde'. When I
>>> first installed horde I checked prefs and this value was ok for me so I
>>> didn't overwrite this pref on prefs.local.php.
>>> - Later on Horde Team decided to change the initial application to 'imp'.
>>> Now, I end up with an installation where the initial app is 'imp' (that I
>>> might not even have installed).
>>>
>>> To avoid this problem we will need to do the following steps:
>>> 1- Backup all config/*.php files
>>> 2- Pull horde code
>>> 3- Compare every single php with the new ones
>>> 4- Update our *.local.php with our new defaults.
>>>
>>> This is almost the procedure that we do now with the exception  
>>> that we don't
>>> need to backup config/*.php files.
>>
>> This is really a constructed example IMO. If we change some  
>> defaults in configuration file, we do this for a good reason. You  
>> might happen to disagree, but chances are good that our changes  
>> make sense.
>
> This is the reasoning I find tremendously flawed.  We as Horde  
> developers might think it makes all the sense in the world, but a  
> local admin might not.  The burden should be on the ADMIN, not us,  
> to change the configuration of a running system.
>
> Not to mention the security concerns.  We ship a configuration  
> default that we think makes sense, and it turns out that it opens a  
> security hole on my particular installation.

I disagree. We could cause the same kind of problems with a code  
change, and separating our responsibility there from our  
responsibility for configuration, or an admins responsibility for  
config updates vs. a patch update, seems like a distinction without a  
difference to me.

-chuck