> On purpose. I think that depending on plugin and hook is horrible, and
> if you really want to do that, you should have to write it explicitly.
Knowing which hook it was is not really necessary.
> Namespaces are fine. If every plugin starts, by convention, all its
> configuration parameters with "${pluginname}/" (or "${pluginname}::" or
> "${pluginname}_") I'm all for it.
I don't think it is a good idea to combine the pluginname and the confname
in one field. Imagine a conf plugin which only knows about configuration for
plugin a and another one which only knows about configuration for plugin b.
Or a plugin which needs to get the config by an sql query like 'select
<confname> from <plugin> where ...'. In all this cases the conf plugin would
need to parse the combined name and extract the plugin name.
I'm still convinced that it would be better to call the conf handler with
seperate parameters for pluginname, confname and probably also instance
number (the :x part). If we do it that way, the conf plugin can decide all
itself if it need to combine the names and in which way.
> But these names should be global: If two plugins ask for the same parameter,
> they should get the same value.
So you mean plugin a should also be access plugins b conf field sample by
accessing 'b::sample'? I'm not sure if this is a good idea, but currently
do not have really formed an opinion.
> If the plugin name is passed implicitly, it isn't possible for two
> plugins to access the same configuration.
Yes. Thats because i did not see an need for a plugin to access "foreign"
conf variables. I normally prefer clean separation. Do you have any example
for what this might be useful?
-kju
--
It's an insane world, but i'm proud to be a part of it. -- Bill Hicks
