Re: Conf: argue !

On 25 Feb 2005 at 14:36, Manuel Holtgrewe wrote:

> Hi

> If you add "language specific defaults" you have a system that is 
> conceptually similar to Apple's Cocoa's. This would be a good thing 
> since we Cocoa is pretty stable and well planned. Don't be afraid, you 
> don't have to know Cocoa. The only thing I want to say is that we would 
> have a configuration schema that is well tested and accepted.

Well, I do not know CoCoa extensively. isn't that about java and desktop 
oriented?

Anyway, the configuration draft doesn't define a new configuration schema.
It takes current BC_technology and optimizes that, to my opinion.
It proposes a technical solution for an existing design for reading 
conf_values. It eliminates Phing, uses as an option sql. No more.
It adds nothing to the design of BC.

Moving to a different configuration structure is another story.
I suspect you can't use Conf:, neither current, neither proposed, in order 
to implement a different configuration interface. See below.
 
> This would effectively change the possible levels and the add a "user" 
> field to the conf table:

Pretty dangerous concept. Though it is a enlightening idea.
I truly doubt that it's usefull in a server environment.
Please do not understand me wrongly: I just have doubts.

>   * levels: factoy defaults, workspace wide defaults, language specific 
> workspace wide defaults, user defaults

It depends totally on how BC manages to have these values seperated.
Current, they have a different path.

>   * user: A foreign key to the corresponding user table's entries.

Example to understand this better:
A website has 653.456 users. Growing each day. Where do you plan to have 
the foreign key in config? What about caching?
I realize that this needs a totally different db_model. But when?

> However, this makes things even more complicated since users might not 
> be allowed to edit all configuration - base url etc. Thus I'd also 
> propose to add a "security level" field:
> 
>   * security level: A string id that is workspace (i.e. project) 
> specific. It must include, however:
>    - "immutable" for XML values that simply cannot be changed
>    - "system" for settings that change things pretty deep in the 
> framework like debug settings.
> 
> We should encourage developers to protect these settings by providing 
> default "static permissions" "edit conf: immutable" and "edit conf: 
> system" and a "roles.Administrator" role that is allowed to edit 
> settings with these levels.

I do not understand this without a clear implementation example on a 
server. I also do have problems with the concept naming:
Conf is one thing, Preferences another one, there are Parameters and 
Definitions as well (ndf). Maybe more. Some have defaults, some can/must 
nbe changed, other ones can be overriden. They all are implemented using a 
php_array.
But to refer to them *all* as Conf: is for me 'a bridge too far'.
At least at this moment.

wim niemans