Re: Conf: argue !

Wim Niemans ri schrieb:
> 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?

It's about Objective C (don't confuse with C++) and yes, it is Mac Os X 
only.

> 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.

The only thing I wanted to say is: "Hey, this looks like something a big 
company uses for they framework in their operating system. And it's not 
any company: It's the company with the most user friendly (and maybe 
developer friendly) operating system and technology. The way they store 
configuration has proven itself over the years. Thus, our changes are 
not unique, but seem right."

>>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.

Okay, so how would you implement user configureable settings 
consistently and so that developers do not need to hack things up?

>>  * 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.

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.

>>  * 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?

Sorry? Where do you want to store the information? You have to store it 
anyway. What I wanted to say is:

  * 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?

>>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.

Did I make clear what I want above? If not, please say so. I can write 
it out in a full document then.

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 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.

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.



Manuel