[augeas-devel] Re: [PATCH] Add PHP module and associated (basic) test file

[Raphaël Pinson]

On Fri, Jul 25, 2008 at 8:41 PM, David Lutterkort <dlutter at redhat.com>wrote:

> On Fri, 2008-07-25 at 13:22 +0200, raphink at gmail.com wrote:
> > # HG changeset patch
> > # User Raphael Pinson <raphink at gmail.com>
> > # Date 1216984947 -7200
> > # Node ID 86411abff2eec6aa4364b7d3f43fe2e94e3ab31c
> > # Parent  a7d566eaab75da9bb533f9c0bc0bd00c4a89caee
> > Add PHP module and associated (basic) test file
>
> > +
> > +   test PHP.lns get conf = ?
>
> The test seems not quite finished.
>
> Also, did you observe that augparse runs _really_ slow with that lens ?
> It seems to allocate a _ton_ of memory. Seems like we need to do some
> optimizations somewhere to keep that at bay.
>

Very slow indeed. Maybe the tip you gave me on dput.aug would improve this.
The fact is that php.aug has _tons_ of keywords. I'm not even sure to have
listed them all. since it seems that PHP modules might allow more here...

There's another problem though. As I was working on this file, it seems
logical to me to treat it as a standard INI file, with sections and
variables. Now I was surprised to find that variables have a naming space in
them, such that most variables exist several times in different naming
spaces (e.g. (ifx,msql,mssql,mysql,mysqli,odbc,pgsql,etc.).allow_persistent.
After noticing that, I wondered if the sections in php.ini were _really_
useful. If the were, what would be the use of adding a naming space to the
variable names? So I talked with a few of my colleagues that are used to
php.ini, and they told me that PHP seems to completely ignore the sections
in php.ini, such that moving variables around has no effect on the
configuration. In that situation. should we consider sections as comments,
seeing that it would be hard to move values around if we use standard INI
file sections?


Raphael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/augeas-devel/attachments/20080726/322e9274/attachment.htm>