[TransWarp] PROPOSAL: rename Local->App, Global->System in peak.config

[Phillip J. Eby]

At 12:24 AM 3/8/03 +0100, Ulrich Eck wrote:

>>I would say that an application is composed of one or more root 
>>components.  An "application configuration" would be
>>the configuration shared by those root components.  This is actually the 
>>intended use of what are now called
>>LocalConfig objects.
>
>I've thought of Local configuration more on "ComponentConfiguration" that
>has a scope that it supplies configuration for itself and all its child
>components. if i write a larger application i might have one "local" 
>configuration
>for the Database part another for the gui part ..
>both fall back to the "application" config and this falls back to "system" 
>config

The above helps to illustrate why I want to change the names; specifically, 
your interpretation of the name LocalConfig runs counter to their actual, 
existing semantics.  :)

Let me clarify two things about configuration scope:

1. Any object that subclasses 'binding.Component' can accept dynamic 
configuration settings which are then made available to its child components.

2. Any object that subclasses 'binding.Base' can have "static" 
configuration, that is to say, bindings whose attribute values can be 
designated as the supplier for a configuration key (interface or property 
name).  The actual values of these configuration items can be dynamically 
determined, but not *which* items are provided.  In any case, as with 
'binding.Component', the provided values are available to their child 
components.

So, there is no need to have a LocalConfig just to provide a "local" 
configuration scope.  LocalConfig was badly named almost from the start, 
because you don't need one in order to have "local" configuration.  You can 
'loadConfigFile()' into *any* 'binding.Component', not just a LocalConfig 
or GlobalConfig.



>if i can use peak.config like this i'ld prefer
>"component" configuration instead of "local"
>"system" configuration instead of "global"

No need; any 'binding.Component' can have 100% dynamic runtime 
configuration for such "local" or "component" configuration.  If you don't 
need that degree of configurability, use 'binding.Base' instead, as its 
lookup process is faster.


>if there is only one "local" config, then App is ok.

There is one AppConfig per simultaneously running application in a given 
interpreter.  The normal case is for there to be at most one application 
per running Python interpreter, and so by default all root components 
associate with the default AppConfig instance.  However, a multi-threaded 
app server could explicitly create multiple AppConfig objects and register 
them for various root components, allowing it to run multiple applications 
in the same interpreter.

Note that this is all *exactly* how PEAK behaves now.  All I'm proposing to 
change are the class and API call names, not any of the behavior.

I'm also now beginning to wonder if I should rename 'binding.Base' to 
'binding.Component', and the existing 'binding.Component' to 
'binding.Configurable', or some such.  But that's an issue for another 
proposal.