[dev] [commits] Horde branch master updated. 89ba60ebd8227e84abe696131778097c4770d99d

[Chuck Hagenbuch]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Chuck Hagenbuch <chuck at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>>> Well, that's where the idea for two files comes from. One lists  
>>>> what we think good defaults are, describes all of the settings,  
>>>> lists options, etc. The second, which is entirely optional,  
>>>> allows users to override the defaults without changing a file  
>>>> that is part of the distribution.
>>>>
>>>> Think of it this way: with this system users automatically get  
>>>> new config settings while maintaining their customizations  
>>>> (except if the setting they're overriding changes, of course - no  
>>>> way around that). And if we pick good defaults, then there are  
>>>> fewer things needed to do out-of-the-box to get Horde up and  
>>>> running.
>>>
>>> It makes more sense to me then to have .xml configuration  
>>> descriptions like we do with conf.php now, and ship default,  
>>> pre-generated .php versions for that.
>>> The .xml generated configuration is pretty cool IMO, admins don't  
>>> have to edit PHP code files, if they don't want to, and still have  
>>> the full flexibility. And we only have a single configuration file.
>>
>> But Horde can still be broken on upgrade until running the config  
>> interface, and if we were to change something really key in horde's  
>> config.php, theoretically you'd *have* to fix the file manually.
>
> We managed to avoid this in the past. Sure, this has to explicitly  
> taken care of in the code, we can't rely on it automatically. But I  
> never experienced this as a high burden in the past.
>
>> Having two files means that user changes are preserved, defaults  
>> can be pre-generated easily, and we can *still* provide a config  
>> UI, either based on xml, or parsed out of the defaults file.
>
> All of this is true with the current system too. Parsing the  
> available features out of the defaults file seems kludgy and error  
> prone to me. Still using XML would mean we'd have to keep 3 files,  
> and two of them actually duplicating information.
>
>> Built-in hooks for a secondary local config file also helps people  
>> out who are changing specific things on specific servers, or doing  
>> vhost-like config changes.
>
> Which is also already possible with the current system.

On this also, anyone else want to weigh in? I remember Michael R.  
being in favor of two PHP config files, and Michael S. not - is that  
right? Any others?

-chuck