[TransWarp] hotload config info

[Phillip J. Eby]

At 07:40 PM 2/9/03 -0800, Joel Boehland wrote:

>I figured out how to load other .ini files into the global configuration 
>space using code like the following:
>config.loadConfigFile(config.getGlobal().__instance_provides__, 
>"conf/module1/module.ini")
> From there, I can pull values out of the global config namespace using 
> code like:
>naming.lookup('config:module1.someproperty/')
>
>This will work, but this sort of feels like a hack, so I'm wondering, is 
>this the right way to approach per-component runtime configuration? Is it 
>advisable to load the components config info into the global config 
>namespace, or should I load it into a per-component config namespace? Is 
>that is even possible?


See peak.config.interfaces...  specifically 'config.IConfigurable'.  Any 
object supporting IConfigurable can be passed to 
config.loadConfigFile().  So the following are all valid:

config.loadConfigFile(config.getGlobal(), "aFilename")
config.loadConfigFile(config.getLocal(), "aFilename")
config.loadConfigFile(someComponentOfMine, "aFileName")

You don't need to use __instance_provides__; that the initialization code 
in config_components does is an evolutionary accident.

Note that 'binding.IComponent' is derived from 'config.IConfigurable', so 
subclassing 'binding.Component' is sufficient to make your component 
configurable via 'config.loadConfigFile()' or other means.


>The other thing that I'm trying to work out is how I would manage 
>component loading/unloading at runtime. It would be useful to be able to 
>remove a component's config info when undeploying a component at runtime, 
>but I'm not sure how I would go about doing that.  Any ideas about this?

If you load the information directly into the component that it's for, as I 
suggest above, normal Python GC will take care of the 
unloading.  'binding.Component' instances carry an internal 
'__instance_provides__' registry that holds all the rules loaded from the 
config files (or other configuration sources).


>  Also, am I using the wrong frameworks to do this? Are the peak or zope3 
> frameworks designed to facilitate component loading/unloading/reloading 
> at runtime?

Not really.  One could possibly use data managers from 'peak.storage' to 
load components on-demand; in that event you would need to use classes that 
look something like this:

from peak.api import model, binding

class Hotloadable(model.Element, binding.Component):
     # ...

I'm not 100% positive this would work correctly.  In principle, it should, 
but in practice there may be some tweaking needed in the inheritance 
graph.  I haven't tried it yet, although I definitely want something like 
it to work in the future.

Anyway, with this approach you could use a 'storage.EntityDM' to 
instantiate the components and configure them, keeping them in its weakref 
cache for as long as you needed them.  In principle, you could perhaps get 
it to save changed configurations as well.  In practice, persisting rules 
would be problematic in the current implementation, as the rules are 
expressed mostly as lambdas or other function templates created on-the-fly.