Re: Conf: argue !

On 25 Feb 2005 at 16:51, alex black wrote:

> > Why can't you guarantee that? Even in MySQL, you can create a "UNIQUE" 
> > typed key - eh?
> 
> uh, yeah you can, with a unique constraint?

Yes, yes. Everybody is right. Let get this cleared.

The new Configuration Draft is about the API of Conf.
Conf is already there, and some genious mechanism is designed to convert 
xml into a php_array that can be read instantly by BC (conf: does that).
The draft introduces a path to the design of Conf. Let's label that as a  
confPath.
The appendices to the draft are showing how you can walk from a php_array 
to a confPath and back.
It suggests offcourse that xml -> php_array -> confPath is equivalent to 
xml -> confPath.
But there is some hidden intelligence in the xsl recipes:
Properties without attributes are silently grouped into an array.

<conf:domain version="2.0" id="smarty" 
  xmlns:conf="http://www.binarycloud.com/ns/conf"
  xmlns="http://www.binarycloud.com/ns/conf">
    <section name="options">

<snip>

        <section name="plugins_dir">
            <property type="raw">BC_PATH_BASE . 
'/smarty/libs/plugins'</property>
            <property type="raw">BC_PATH_BASE . '/smarty-
plugins'</property>
        </section>
    </section>
</conf:domain>

Will become :

return array(
    'id' => 'smarty',
    'options' => array(

<snip>
 
       'plugins_dir' => array(
            (BC_PATH_BASE . '/smarty/libs/plugins'),
            (BC_PATH_BASE . '/smarty-plugins'),
        ),
    ),


Ergo. If we walk from xml -> confPath then non-unique paths will pop up.
Ergo. an unique confPath cannot be guaranteed.

Definitely we can force uniqueness of a confPath by adding constraints to 
the database. 
The syntax of a php_array already does enforce this.
But the xml format does *not*.

Now, one may conclude that xml is out for BC.
As an option we could build the very same 'intelligence' into Conf as 
Phing spreads when building php_arrays from conf.xml.

Solve it as (1):

/smarty
/smarty/options
/smarty/options/plugins_dir
/smarty/options/plugins_dir/0 =>(BC_PATH_BASE . '/smarty/libs/plugins')
/smarty/options/plugins_dir/1 =>(BC_PATH_BASE . '/smarty-plugins')

(which will break current BC, I guess)

Or (2):

/smarty
/smarty/options
/smarty/options/plugins_dir  =>(BC_PATH_BASE . '/smarty/libs/plugins')
/smarty/options/plugins_dir  =>(BC_PATH_BASE . '/smarty-plugins')

(and have Conf group these into an array)

Or (3):

/smarty
/smarty/options
/smarty/options/plugins_dir => array(
       (BC_PATH_BASE .  '/smarty/libs/plugins'),
       (BC_PATH_BASE . '/smarty-plugins') )

(and allow for arrays in the value).

Though this aspect is *not* of concern to the API, it is a discussion on 
the implementation of the API onto SQL.

So, having the real world (xml) saying: path is not unique
And BC (php)  saying: path must be unique
What do tell we the database ? This is a design aspect.
Anyhow DESIGN prescribes, technology will solve it.

My preferences?

(1) Yacc. Looks like hacking.

(2) Elegant. Makes Path being non-unique (in the database only).

(3) Possible. Powerfull. Introduces customized data format in the 
database.

Now, let's vote.

Cheers,
wim niemans

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