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

[Michael Rubinsky]

Quoting Chuck Hagenbuch <chuck at horde.org>:

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

Yup. I still agree with Chuck's original idea of shipping a "default"  
*.php file and allowing local overrides.  I really don't think that it  
adds any complexity, and IMO provides an easier experience out of the  
box while still providing for a fairly easy way to customize things.  
As far as .php vs .xml files goes - I think that for things like  
prefs.php it makes sense to keep the files as php as opposed to auto  
generating them like we do for the conf.php file...this allows easier  
overriding/customization.


Thanks,
mike

--
The Horde Project (www.horde.org)
mrubinsk at horde.org

"Time just hates me. That's why it made me an adult." - Josh Joplin