Re: [Phpwiki-talk] Automatic config rewriter php -> ini

[Reini U. <ru...@x-...>]

Dan Frankowski schrieb:
> One disadvantage: you'll always support two ways (ini and php). This 
> requires more code maintenance. I claim you'd be happier if you could 
> somehow easily migrate people, so in the end you only support one way. 
> For example, offer a tool that takes an index.php and makes an INI file 
> out of it. Then this tool can be deprecated and go away after a few 
> releases.
> 
> In general, supporting fewer ways to do the same thing in the long run 
> is good.

No, we are talking about two things:

1. convert an existing old index.php to config/config.ini for
    easier upgrades from < 1.3.10 to > 1.3.10
    joby said he had something like this in the works.

2. dump the content of an new existing config/config.ini to a
    config/config.php (after timestamp comparison), for faster
    load time. This is Matthew's idea. mediawiki's installer does
    something like this also. The problem is the needed file
    permission, similar to upload. Maybe we should ship an empty
    but 446 config/config.php. (For freebsd it's easier, they
    know the apache user in advance)

> Joby Walker wrote:
>> Matthew Palmer wrote:
>>> Has anyone made any progress in this area?  The major hold-up for me
>>> updating Debian to 1.3.1[01] is that it'll force every PHPWiki user in
>>> Debian to rewrite their config files, which is unlikely to make them 
>>> jump
>>> for joy.
>>
>>
>>
>> I'm a good way toward being done.  Been busy with work, getting a new 
>> laptop, and rebuilding my windows server at home.  Once I have the CLI 
>> client working and tested I'll commit it.
>>
>>>
>>> I did have one (potential) brain-wave, which would also, as a 
>>> side-effect,
>>> solve the major cause of complaint against the ini-file system.  Put
>>> together code which parses the INI file and writes a config.php full of
>>> define()s and whatever else takes your fancy, and source *that* 
>>> instead of
>>> doing an INI parse every invocation.  Then, just have a bit of code that
>>> compares the mtime of config.ini with that of config.php, and rewrite
>>> config.php if it's older than config.ini.  The first user to hit the new
>>> config file gets a 1-2 second slowdown, maybe, but that can be server 
>>> lag,
>>> and everyone else gets smokingly fast response times.
>>>
>>
>> Yeah thought of that too.  It'll be an option for the CLI client to 
>> build a config.php.  Then if config.php is present it'll use it 
>> instead of config.ini.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/