phpwiki-talk

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

[Matthew P. <mp...@he...>]

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

This also means that I can continue (more or less) to let Debian users work
on their config.php files directly if they have to, and switch to config.ini
when it suits them.  This, of course, pre-supposes that the defines and such
for 1.3.10 are very close to those of 1.3.7, but I was careful to leave as
much of it intact as possible.

Does this sound like a monumentally stupid, or clever, thing?  I haven't
been tracking the addition / renaming of config items, which is the big flaw
in my plan.  Reini, has there been that much modification to the system such
that 1.3.7 config.php files would have no chance of working in 1.3.10?

- Matt

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

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

Matthew Palmer schrieb:
> 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 hoped joby wants to do that, because my time is very limited with 
testing and bug hunting.
It's not really hard to write though.

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

good idea!

> This also means that I can continue (more or less) to let Debian users work
> on their config.php files directly if they have to, and switch to config.ini
> when it suits them.  This, of course, pre-supposes that the defines and such
> for 1.3.10 are very close to those of 1.3.7, but I was careful to leave as
> much of it intact as possible.
> 
> Does this sound like a monumentally stupid, or clever, thing?  

clever.

> I haven't been tracking the addition / renaming of config items, which is the big flaw
> in my plan.  Reini, has there been that much modification to the system such
> that 1.3.7 config.php files would have no chance of working in 1.3.10?

yes, I think there were a lot of such minor and dirty changes.
It broke phpwiki.sf.net/demo for a week or so, because we forgot to 
check an important config variable.

We have now config-default values, and the step after reading in the 
options moved from config.php to IniConfig.php:fix_configs().

The names didn't change at all (besides the new global $charset), but 
the logic changed.
So the config.php dumper should check against config-default.ini before, 
do the fix_config() call and then dump it.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

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

[Joby W. <joby@u.washington.edu>]

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.

jbw

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

[Dan F. <dfr...@cs...>]

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.

Just an idea.

Dan

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.
>
> jbw
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

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/

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

[Joby W. <joby@u.washington.edu>]

Actually I was talking about a variant of #2.  Instead of an 
auto-creation of config.php (based of timestamp, etc), when using the 
CLI tool you can create a config.php from your config.ini.

#1 isn't a bad idea either, I'll put it on my todo list (though it won't 
make my initial commit).

Joby Walker
C&C Computer Operations Software Support Group


Reini Urban wrote:
> 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.

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

[Oliver B. <ob...@de...>]

Reini Urban wrote:

> 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

after all, what's the advantage of the INI file over the old *.php,  
avoiding the "if (!defined..."?

Oliver
-- 
Oliver Betz, Muenchen

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

[Joby W. <joby@u.washington.edu>]

1) Ease of manual configuration - particularly for the non php inclined. 
  2) Encourages better config behavior rather than large collections of 
arrays.
3) Would allow for other tools to be developed to edit the configuration.
4) others...


Joby Walker




Oliver Betz wrote:
> Reini Urban wrote:
> 
> 
>>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
> 
> 
> after all, what's the advantage of the INI file over the old *.php,  
> avoiding the "if (!defined..."?
> 
> Oliver

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

[Matthew P. <mp...@he...>]

On Thu, Jun 17, 2004 at 09:48:56PM +0200, Oliver Betz wrote:
> Reini Urban wrote:
> 
> > 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
> 
> after all, what's the advantage of the INI file over the old *.php,  
> avoiding the "if (!defined..."?

Not executable, far easier syntax, far more *regular* syntax, and the range
of potential errors is far less.

- Matt