Breaking the rules a bit, I've created a config_plugins table that allows us to break down config values into per-module or per-plugin sets. This table is now on HEAD and MOODLE_15_STABLE.
(Don't panic just yet -- we are *not* migrating the existing code to use this new table at this time.)
The table is (prefix)config_plugin and is similar to the current config, except that it has a "plugin" field.
- id
- plugin not null
- name not null
- value not null
+ unique (module,name)
The convention for the 'plugin' field is to use 'auth/foo' for entries related to the foo auth plugin, and 'mod/bar' or 'mod/pub' for those of the beer dispensing module.
A couple of related functions are coming soon to a stable branch near you:
- get_config_plugin($plugin , [$name]) which knows to return a $config object with all the "name" values mapped to object properties, as well as a single value
- set_config_plugin($plugin,$field,$value) does what you'd expect
The rationale behind this is that config is growing, which isn't bad per-se, but we fetch it from database into memory on every request. We are doing it now because some changes I am making for the release are going to add many new config entries, making the problem worse.
At 1.5 release time this will only be used by some funky Auth code that I am working on. If this turns out to be a good idea, migration can happen on HEAD over the 1.6/1.7 lifecycles.
I would call 'moodle' and 'core' reserved plugin names for the time being. Just in case we want to migrate all of config to this new table, and we need a "natural" name for the plugin field.
Cheers!
(Edit: fixed function names)
BTW: I've postponed committing the version bump on MOODLE_15_STABLE until tomorrow. Last chance! 
I think you should change the function names you use for this to just extend the existing set_config that we have:
set_config($field,$value,$plugin=NULL)
get_config($plugin=NULL, $name=NULL)
If plugin = NULL, then use config table as now (existing logic), otherwise use new table.
set_config($field,$value,$plugin=NULL)
get_config($plugin=NULL, $name=NULL)
If plugin = NULL, then use config table as now (existing logic), otherwise use new table.
Makes sense to me.
get_config($name=NULL, $plugin=NULL)
maybe? (changed parameter order)
maybe? (changed parameter order)
We don't use get_config($name) because it's in $CFG, but either way... 
This is a good idea. Dealing with configuration data, figuring out what data is own by whom, this is a fundamental consideration.
It's also a good time to clarify, perhaps with a bit more
rigor, the data design and name space for this data.
While it's relatively clear what is going on, I'd be happier if I saw
this expressed in XSD. My claim is that by using XSD we
could address all the configuration data using separable and well
defined name spaces, and it will all map back to SQL or relational DB.
XSDs also can map right into objects or procedures in PHP.
Since the data here is primarily (if not entirely) name=value pairs,
expression in XML is simple. This could be a flat namespace,
but I think there is in fact hierarchy. Something like
Moodle instance/Global
Module/local to module
is desirable. This allows for local config values to a Module/plugin.
The possibility of inheritance is here too, which is to say a plugin can inherit
the config values from a higher level.
Using XSD mostly buys you both an abstract data representation and allows for namespaces to coexist. I think this would also be good for module creators to provide, again a bit of rigor. Down the road, this would setup Web Services possbilities.
My team is doing such an exercise right now for our eTEACH project, and we are going create a Moodle module for our authoring tool. We've got quite a bit of "config" data which fits the name=value model. There is some nesting of the data, we have tools that each "own" some data, that we are handling with separate XSD namespaces. We are weaving in Dublin Core and LOM metadata, that's easy with existing XSD/DTDs for each (DC is a subset of LOM).
It's also a good time to clarify, perhaps with a bit more
rigor, the data design and name space for this data.
While it's relatively clear what is going on, I'd be happier if I saw
this expressed in XSD. My claim is that by using XSD we
could address all the configuration data using separable and well
defined name spaces, and it will all map back to SQL or relational DB.
XSDs also can map right into objects or procedures in PHP.
Since the data here is primarily (if not entirely) name=value pairs,
expression in XML is simple. This could be a flat namespace,
but I think there is in fact hierarchy. Something like
Moodle instance/Global
Module/local to module
is desirable. This allows for local config values to a Module/plugin.
The possibility of inheritance is here too, which is to say a plugin can inherit
the config values from a higher level.
Using XSD mostly buys you both an abstract data representation and allows for namespaces to coexist. I think this would also be good for module creators to provide, again a bit of rigor. Down the road, this would setup Web Services possbilities.
My team is doing such an exercise right now for our eTEACH project, and we are going create a Moodle module for our authoring tool. We've got quite a bit of "config" data which fits the name=value model. There is some nesting of the data, we have tools that each "own" some data, that we are handling with separate XSD namespaces. We are weaving in Dublin Core and LOM metadata, that's easy with existing XSD/DTDs for each (DC is a subset of LOM).
I don't have your background in this area, so I can't see why you would want to complicate a very simple list of values with XML schema, or why mapping it onto a simple relational table would be better than just using the relation directly.
Could you please give an example to help clarify what you mean?
Could you please give an example to help clarify what you mean?
This may be a 1/2 or 1/4 baked idea on my part
There's several concepts I am mushing together.
But, let me follow thru a bit more and see where my brain takes us!
1. XML is useful as a serialization format for when the data lives outside the DB.
For config data, this would be a reasonable way to have defaults.
A "factory default" setting. No need to clutter up the DB.
This is similar to the old DOS/Win .ini files.
These would be loaded into the DB at initialization time.
Another use would be the "exchange" of a Moodle module, complete with
current config values, to another wholly separate instance of Moodle.
2. Config values need name spaces.
The names picked need a naming convention so as not to collide.
This is an issue when you use some feature in multiple places.
The typical approach these days is to have a hierarchical name
space. org.moodle would be the top of Moodle's name space
(or moodle.org in DNS style).
Both objects (within some programming lang) and XML can use
this style of name space convention.
This would allow a module creator to "own" a name space, like
com.cyberedu or edu.wisc.doit.engage. A nice clean distinction which
applies to all code, not just the config values.
3. Client side "objects" need values too.
It's not just the server side PHP that needs to know about the values.
Client side "objects" in JS, Flash, Java should have them too.
XML as a serialized represention is an obvious choice.
This is what we are doing in our eTEACH module, passing values
"over the wire" in XML using SOAP.
4. Providing well defined data models is important.
Being able to say "my data model looks like this", and to have some
agreed upon format for this will become more and more important.
UML is one way to do this (using ERD features).
XSD would be equivalent in a formal sense. Many other representations
are equiv too, but I'm trying to look at this from a "generic technology"
perspective. It's quite possible to generate XSD from an XML data
fragment and quite possible to generate XML from SQL.
Going forward, as Moodle grows, it will become more important
to have some rigor and be able to have well defined (and documented)
data models. There is a bit of legitimacy in the eyes of some
(read CIOs and IT architects) in doing this exercise, it means someone
has done their engineering homework.
This may be a bit much at the moment to take in for Moodle.
As I say, I'm working with several concepts all at once...
There's several concepts I am mushing together.
But, let me follow thru a bit more and see where my brain takes us!
1. XML is useful as a serialization format for when the data lives outside the DB.
For config data, this would be a reasonable way to have defaults.
A "factory default" setting. No need to clutter up the DB.
This is similar to the old DOS/Win .ini files.
These would be loaded into the DB at initialization time.
Another use would be the "exchange" of a Moodle module, complete with
current config values, to another wholly separate instance of Moodle.
2. Config values need name spaces.
The names picked need a naming convention so as not to collide.
This is an issue when you use some feature in multiple places.
The typical approach these days is to have a hierarchical name
space. org.moodle would be the top of Moodle's name space
(or moodle.org in DNS style).
Both objects (within some programming lang) and XML can use
this style of name space convention.
This would allow a module creator to "own" a name space, like
com.cyberedu or edu.wisc.doit.engage. A nice clean distinction which
applies to all code, not just the config values.
3. Client side "objects" need values too.
It's not just the server side PHP that needs to know about the values.
Client side "objects" in JS, Flash, Java should have them too.
XML as a serialized represention is an obvious choice.
This is what we are doing in our eTEACH module, passing values
"over the wire" in XML using SOAP.
4. Providing well defined data models is important.
Being able to say "my data model looks like this", and to have some
agreed upon format for this will become more and more important.
UML is one way to do this (using ERD features).
XSD would be equivalent in a formal sense. Many other representations
are equiv too, but I'm trying to look at this from a "generic technology"
perspective. It's quite possible to generate XSD from an XML data
fragment and quite possible to generate XML from SQL.
Going forward, as Moodle grows, it will become more important
to have some rigor and be able to have well defined (and documented)
data models. There is a bit of legitimacy in the eyes of some
(read CIOs and IT architects) in doing this exercise, it means someone
has done their engineering homework.
This may be a bit much at the moment to take in for Moodle.
As I say, I'm working with several concepts all at once...
Ah, OK. Yes, we have something like that in this table, which is the same as what we do in the CSS class naming, which is to mirror the directory structure of moodle itself.
The css class for the assignment module pages is mod-assignment, and the "plugin" name for config values in this new table will be something similar like mod/assignment (as Martin L. explained in the initial post here)
This is a very natural and easy-to-understand way to name things without conflict, since directories must be unique.
There's no need for default values in a separate text file, though, because the modules themselves check for missing values and create default values for missing ones, as part of robust self-checking. Having to parse an external file all the time for that would be too slow (and not any more useful in this case)
The css class for the assignment module pages is mod-assignment, and the "plugin" name for config values in this new table will be something similar like mod/assignment (as Martin L. explained in the initial post here)
This is a very natural and easy-to-understand way to name things without conflict, since directories must be unique.
There's no need for default values in a separate text file, though, because the modules themselves check for missing values and create default values for missing ones, as part of robust self-checking. Having to parse an external file all the time for that would be too slow (and not any more useful in this case)
Backing away from XSD now and just focusing on name space ...
assignment.moodle.org (DNS)
would be the name space. that's the same as
moodle.org/assignment (URL w/ path)
or
org.moodle.assignment (package for object)
this is fine for core modules. For non-core, I would see doing
something that allows for another org to hold the DNS.
For example, in our eTEACH we would do
eteach.engage.doit.wisc.edu
as our top level name space. I think it's important to not
comingle this with moodle.org, given it's a separate code base
and separately maintained and owned by the University of Wisconsin.
Even with our Public License, it's still our code (in this version).
Now, within a Moodle module, are the values we use under
org.moodle.eteach
or
moodle.eteach.engage.wisc.edu
?
Just to make this a bit more interesting, there is a local s/w company we
are working with and they are releasing code from media-landscape.com
as part of eTEACH. They could take the version of eTEACH we are developing
and make a derivative work. This could result in a Moodle module that
would be a commercial offering.
Perhaps this is a moot point at the moment. I just see that now is a good time, before things get any more complex within Moodle, to clearly define how
name spaces work. Who "owns" what does play into this.
assignment.moodle.org (DNS)
would be the name space. that's the same as
moodle.org/assignment (URL w/ path)
or
org.moodle.assignment (package for object)
this is fine for core modules. For non-core, I would see doing
something that allows for another org to hold the DNS.
For example, in our eTEACH we would do
eteach.engage.doit.wisc.edu
as our top level name space. I think it's important to not
comingle this with moodle.org, given it's a separate code base
and separately maintained and owned by the University of Wisconsin.
Even with our Public License, it's still our code (in this version).
Now, within a Moodle module, are the values we use under
org.moodle.eteach
or
moodle.eteach.engage.wisc.edu
?
Just to make this a bit more interesting, there is a local s/w company we
are working with and they are releasing code from media-landscape.com
as part of eTEACH. They could take the version of eTEACH we are developing
and make a derivative work. This could result in a Moodle module that
would be a commercial offering.
Perhaps this is a moot point at the moment. I just see that now is a good time, before things get any more complex within Moodle, to clearly define how
name spaces work. Who "owns" what does play into this.
> While it's relatively clear what is going on, I'd be happier if
> I saw this expressed in XSD. My claim is that by using XSD we
> could address all the configuration data using separable and well
> defined name spaces, and it will all map back to SQL or
> relational DB. XSDs also can map right into objects or procedures
> in PHP.
You can always trust Moodle to have SQL schemas -- we couldn't do without them. If you want XSD, generate it from the SQL schema.
> Using XSD mostly buys you both an abstract data representation
> and allows for namespaces to coexist.
Yup, almost like SQL schemas -- which are mostly abstract, but also have enough info for the RDBMS to actually do something useful. You can safely abstract all that and create alternative representations.
I recently did something like that, using a Perl script to figure out the correct foreign keys in the Moodle schema, to [feed them to schemaball](http://moodle.org/mod/forum/search.php?id=5&words=schemaball&phrase=¬words=&fullwords=&hfromday=1&hfrommonth=1&hfromyear=1&hfromhour=1&hfromminute=1&htoday=1&htomonth=1&htoyear=1&htohour=1&htominute=1&forumid=0&subject=&user=).
> I saw this expressed in XSD. My claim is that by using XSD we
> could address all the configuration data using separable and well
> defined name spaces, and it will all map back to SQL or
> relational DB. XSDs also can map right into objects or procedures
> in PHP.
You can always trust Moodle to have SQL schemas -- we couldn't do without them. If you want XSD, generate it from the SQL schema.
> Using XSD mostly buys you both an abstract data representation
> and allows for namespaces to coexist.
Yup, almost like SQL schemas -- which are mostly abstract, but also have enough info for the RDBMS to actually do something useful. You can safely abstract all that and create alternative representations.
I recently did something like that, using a Perl script to figure out the correct foreign keys in the Moodle schema, to [feed them to schemaball](http://moodle.org/mod/forum/search.php?id=5&words=schemaball&phrase=¬words=&fullwords=&hfromday=1&hfrommonth=1&hfromyear=1&hfromhour=1&hfromminute=1&htoday=1&htomonth=1&htoyear=1&htohour=1&htominute=1&forumid=0&subject=&user=).