Re: Conf: argue !

> Sorry? As far as I imagined the things we discussed here, you first 
> load factory defaults, then load other configuration and overwrite the 
> configuration values with the same path.

This is also my understanding.

>  * Have a table entry for factory defaults with path XXX
>  * Have a table entry for project (workspace) defaults with path XXX 
> overriding the factory defaults.
>  * Have a table entry for user defaults that are associated with each 
> user with path XXX overriding factory and project defaults.
>
> In my very humble opinion this is simple, clear and nearly fool proof. 
> What did you mean then? How would you implement all this?

I think he wants to implement it the exact same way, eh wim?

Anyway I agree with this method completely. It's simple, no magic, easy 
to debug and understand.

Simply cache the resulting PHP array somewhere (a nice php file) and 
you have system configuration ready n' waitin n' fast. Great.

This is a very simple design, and it was my original (and current) 
understanding of wim's proposal.

> The different naming of configuration values and node parameters are 
> intended - or do we want to merge them (I'm open for both ways here!).

I am open to both ways also, but not now. Not yet :) we have other 
things to finish first and NDF works so let's not freaking touch it.

> I meant the meaning of "preferences" in the same way as 
> "configuration". They are basically the same thing and not taking them 
> as one thing makes everything more complex. With all configuration 
> stored and handled by Conf, you only have one class to access them and 
> overriding can be done by the configuration class.

Of course you have quite different requirements for the two sets 
though: reading some app config that is per-user at startup and caching 
it is one thing, such a process for 500k users is insane.

However! The basic "path getting and setting" thing I do think is a 
very good thing for "user" preferences for a public site.

> If you seperate system configuration and user preferences, you'd have 
> to do the mergin and overriding in your user code: Everywhere you need 
> it.

Yes, true.

Guys for the moment we should leave the "user preferences" thing alone 
and just ensure that the basic conf redesign is happy. Then and only 
then should we deal with "user prefs" getting and setting (and all the 
problems associated with it).

_a