[dev] default backends

[Jan Schneider]

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

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Vilius ?umskas <vilius at lnk.lt>:
>>
>>> Sveiki,
>>>
>>> Monday, February 14, 2011, 9:58:33 PM, you wrote:
>>>
>>>> Quoting 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.
>>>
>>>> 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.
>>>
>>> As an ex-admin I agree here with Michael completely. Usually what I do
>>> when upgrading, is:
>>>
>>> 1. Backup whole Horde tree.
>>> 2. cvs/git update it.
>>> 3.  diff the new config files with backup config files for changes and
>>> adjust new files accordingly.
>>
>> 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.
>
> This is not an accurate statement though - upgrading is not that  
> simple.  There seems to be two assumptions you are making with this  
> new config layout:
>
> 1. Horde should work by default in a new install.
> 2. Horde should work by default after updating.
>
> I agree with #1.  Especially since a use case for a new user is to  
> test-drive the software before deciding to use it, at which point  
> they can do a more thorough install.
>
> I totally disagree with #2.  In fact, one can argue that this is  
> tremendously dangerous behavior.  It is quite possible that a  
> default configuration option that is changed/added in a file is  
> exactly opposite of what the admin wants, or what the admin was  
> doing previously.  You are assuming that we, as Horde developers,  
> will not make changes that will change previous behavior, but there  
> is no way we can guarantee that.
>
> As an admin, once I configure a system I expect my configuration to  
> remain.  If a future version of the software breaks things, I accept  
> that issue and will read/learn about the change and then manually  
> change my configuration.  But if a future version of the software  
> changes some critical setting, or even some non-critical setting,  
> without me knowing about it, that is unacceptable to me (it is  
> completely irrelevant if Horde's developers feel that the change is  
> not significant).

I can only repeat myself. We do this all the time already. We add new  
feature, we change behavior, sometimes even without any configuration  
option.

Also, since this might not be clear from the discussion, this does not  
affect the main configuration in conf.php at all. That is still done  
through conf.xml and the configuration UI, and you can still verify  
the diff between the old the new configuration before saving it.
This only affects backends.php and stuff like  
turba/config/attributes.php or ingo/config/fields.php, the latter  
which really don't impose *any* security concerns at all.

Jan.

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