[dev] Changing configuration file format

[Andy Dorman]

On 06/07/2013 03:14 PM, Michael M Slusarz wrote:
> Quoting Jan Schneider <jan at horde.org>:
>
>> Considering the increasing post to the mailing lists of people having
>> problems creating their *.local.php files, we should consider going
>> back to a line-oriented configuration file format, like we use in the
>> generated conf.php files.
>> I prefer the current format too, but especially for less experienced
>> administrators it's much easier to copy single lines from a
>> backends.php file to a backends.local.php file and just change their
>> values. Building such a line from the current nested hash structures
>> is impossible without at least some PHP knowledge, and still tedious
>> even for experienced administrators. This often ends up in users
>> copying the complete configuration hash into the *.local.php files
>> which is exactly what we *don't* want.
>
> I disagree. It is going to make the examples unreadable.
>
> When we first made the change to the *.local.php files, I did this for
> an example file and it just killed my eyes (it's bad enough with the
> conf.php files - it's impossible to find anything in there). Just
> imagine IMP's prefs.php in this kind of format. It would be a 100KB file
> - this is just making it MORE difficult to figure out what to copy/paste
> and making it more likely that someone is just going to copy the whole
> file over and change that, which
>
> For the record - the probability that admin's were going to copy/paste
> the entire file was one of my arguments against moving to *.local.php
> files in the first place. While I agreed that it makes sense from an
> upgrading persepective, the issue IMHO is that no other software does
> things this way so it is not intuitive to an admin. That is where most
> of the confusion is coming from, not the PHP formatting in the file.
>
> I think the more proper solution(s) in H6 would be one of the following:
>
> 1. Force an admin to run an upgrade script, where these kind of things
> could be checked for. In the PHP world, you can take a look at
> http://galleryproject.org/ as an example of how this works. (This is
> much preferable to trying to do upgrade tasks via the Horde_LoginTasks
> mechanism, which has always been sort of a hack).
> 2. Unify all configuration files into a single file with a common
> configuration syntax, to reduce admin confusion.
> 3. Make everything a "preference", since we already have a system in
> place there to automatically upgrade default values.
>
> michael
>
Just my 2-cents worth as an system admin.

We have only been back working with Horde for a couple of weeks now 
after a 3-year hiatus to help a big customer set up Drupal sites for a 
bunch of domains.

We are a Debian shop and planning on upgrading a cluster of web servers 
from H3/IMP to H5/GroupwareWebmail.

Coming from H3 I must let you know that your move to *.local.php files 
has made our job fantastically easier and less prone to error.  Once we 
get our local config files updated on our beta server, we distribute 
them across our cluster, and run apt-get update on each without worrying 
about clobbering our local configs.  And we all really appreciate that.

So whatever you change, please do not move away from local config files 
that are protected from being clobbered by ordinary Horde updates.

Thank you and really big thanks for all your work on Horde.

-- 
Andy Dorman