[dev] Changing configuration file format

[Luis Felipe Marzagao]

Em 07-06-2013 18:49, Andy Dorman escreveu:
> 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.
>

I agree. Having to backup/recreate conf.php files on each upgrade is 
much more tedius than one-time local.php creation.

I think the config files have a lot of examples and a lot of warnings 
("...do not edit this file") so that even unexperienced php users/admins 
can manipulate .local.php files just fine.

Yes, maybe someone will make a complete copy/paste of a config array 
(gollem backends.php is the perfect candidate for that), but then, if 
one chooses that approach, it's one's job to verify everything is the 
same after an update on the original conf file and make proper 
adjustments if it isn't. No big harm on that.

The benefit from local.php, in my opinion, outranks any disadvantages 
this approach may have.

Luis Felipe