Re: Conf: argue !

Hi

> It's not an issue. The design says 
> 
>         //domain_name / section_name [/.......] / property_name => value

This should be /domain_name... in my opinion - just a minor point.

> So it *clearly* does not allow for properties without a name.
> Since arrays are not considered any more, your example is illegal:
> this cannot be done within the design.
> 
> One may argue that we need numerics as a property_name. Sure.
> The impact on the code is huge since the php-trick has to be neutralized.
> But whatever the list is voting for, it will be done.
> 
> Please note that in above example for '/smarty', the 'plugins-dir' moves 
> from a section into a property. Didn't see a comment on that 'feature'.

Duplicate ids are bad in my opinion. But that's only me, of course.

> Maybe you work the numeric key out in a proper way, including rules for 
> the numerics  in the name ('must be consequetive', 'can't be set', 'can't 
> be mixed with alfa_names', 'must be sort_able', 'whatever'). Show the 
> impact when the array(foo,bar) changes into array(bar,foo) and make it a 
> conceptual design.
> The effort to do that is such heavy and confusing that you would gladly 
> propose 'Why don't we allow for arrays in the value'.
> Don't understand me wrong here: that's the path I walked already.

Okay, that is clear to me now. Sorry for misunderstanding you before.
However, 'Why don't we allow for arrays in the value' will not help here
if you really only want path querying either as far as I can see - will
it? So the path querying seems to be the limit (yes, you said so above,
but I only want to make sure I understand you 100%).

I think that the current XML configuration format is good and we should
allow the same structures in SQL, too.

The point is what we want to allow as a query language. "Real" XPath is
not the thing we want here, since you have to specify the namespace with
each querying. Your example from above would become:

     /conf:domain[@id='foo']/conf:section[@name='bar'] \
          /conf:property[@name='rex']

This is a bit complex.

Additionally, I do not think we need the "search the whole tree for a
certain tag" feature of XPath. Something like the following is not
required for configuration in my opinion:

     //conf:property[@name = 'myname']

I only gave some examples form XPath because it seems to be pretty
complete for querying trees.

So, what do we want in our query language? I think we should allow for
the same things that we can currently do with our XML configuration
files loaded by Conf. There is currently now querying, but you can do
the following:

     $conf =& Conf::getInstance();
     $settings = $conf->getConf('node');

     $foo = $settings['bar']['foo'];
     $bar = $settings['moo']['bar'];
     foreach ($key => $value in $settings['bwahaha']) {}
     for ($i = 0; $i < count($settings['whatever']['moo']); $i++) {
         print "$i = " . $settings['whatever']['moo'][$i];
     }

So I think that we should allow for numeric arrays and associative
arrays. I think we need them for the following two reasons: First, you
do not want to key (or can key) everything. Sometimes, you just want
lists of strings. Second, we want to pass the configuration for
datasources pretty rawly to the drivers - without having to write
wrappers where we do not have to. Thus, we should allow to create
arbitrary PHP array structures.

There are two things that we can do now - *if* we want to allow for
arbitrary array structures:

  * Do not allow querying beyond numeric arrays. This is not so big a
problem as it sounds because in configuration files, you normally store
a pretty flat list (2-4 levels at max from my experience) of values that
you want to query for. These then have arbitrary structure, but you
normally do not query within this structure. If anyone finds an example
where he wants to query beyond a numeric array, please tell me. (Note: I
do not take implementation into consideration at the moment, only the
query "language")
  * Allow to query beyond numeric arrays. This can be done by simply
passing in the integer into the path: /domain/list/1/title. This is
doable, but complex in implementation. However, let's do not care about
implementation for now.

*m

_______________________________________________
dev mailing list
dev-PnctHDZWAvB/Cz2I37pSEPZ4XP/[email protected]
http://lists.binarycloud.com/mailman/listinfo/dev