[TransWarp] Action Plan for the Eradication of Singletons

[Phillip J. Eby]

Here's what I've decided:

* Default configurations are no more.  'config.iterParents()' will go only 
to the root of the supplied component, and no further.

* All 'config' API's related to SystemConfig and AppConfig objects will 
disappear.  (About 9 functions in all from peak.config.api_impl.)

* The BasicConfig/AppConfig/SysConfig classes will be refactored to form a 
single class, 'Application'.  'config.Application' will be set up such that 
if you want the default behavior of loading 'peak.ini' and the file 
specified by 'PEAK_CONFIG', you get it, but can easily adjust those 
behaviors with keyword arguments or by subclassing.

* No changes will be made to the current mechanics of setting or getting 
parent components, BUT we will still implement some means for a constructor 
to "suggest" to a contained component that the container is its parent.

* Configuration lookups (for properties and utilities) that go past the 
root component of the lookup context, will result in a special error 
message if the root component doesn't support 
'config.IConfigurationRoot'.  If the root component *does* support the 
interface, then they will behave as they would now upon reaching the end of 
the search.  (Note that for 'config.findUtilities()' this means that it 
will *always* raise the error if the root doesn't support the interface, 
because 'findUtilities()' always goes "past the root" in its search.)  The 
special error message will indicate that the lookup context is not part of 
an "application", as its root component is not a configuration root.

* binding.lookupComponent() will not attempt to carry acquisition of 
non-URL names "past the root" into the naming system if the root does not 
implement IConfigurationRoot.


As a result of the above changes, it will be necessary to have a 
'config.Application' object (or similar IConfigurationRoot implementation) 
in order to use the configuration or naming systems.  It is highly 
recommended that only startup scripts (e.g. __name__=="__main__"), test 
suites, and application servers create 'config.Application' instances, in 
order to avoid unintentional duplication of services or divergence of 
configuration values.  Example usage:

from peak.api import *
app = config.Application()

db = naming.lookup('something', app)

storage.begin(app)
# blah blah
storage.commit(app)

(Okay, so I was impatient and used abbreviations this time...)

I'm still open to using a name other than 'Application'.  It may give the 
impression that you need to subclass it to create an application.  However, 
it *would* be safe to subclass it as a basis for an application, as long as 
you were sure the component in question would be *used* as an 
application.  I'm afraid people would go around creating Application 
subclasses when they aren't really necessary, and then make an application 
out of six Application subclass instances, each of which is going to load 
'peak.ini'.

For right now, I'm going to go ahead and start coding with the name 
'Application', but I'd like to hear some more input on the subject before 
finalizing the name.  Some major contenders for the name are 'RootConfig' 
and 'ConfigRoot' -- they sound like the interface, and don't sound like you 
should subclass them.  Maybe even 'config.RootComponent', although that 
sounds like maybe you would want to subclass it.

Anyway...  if you have thoughts on the name, please speak up.