It has become apparent that there are some options for the calendar (do admins see all course events? which days are in weekends? and much more, I 'm sure) which don't really fit in the "personal preferences". Hell, even the "personal preferences" were a compromise from my point of view, because there's nothing like them in all of Moodle so they should probably be going into the user profile. But touching the user profile was taboo at the time, and I also didn't want to clutter it. Thus the compromise, for those settings which people would find it impossible to live without.
It's pretty much the same situation again, only on a more esoteric level. We need a configuration panel for the calendar. The logical place would be the administration screen. But does it justify one more entry? Also, the DMS needs some such panel. Does that justify one more entry, considering that it's not even part of the standard install? If it doesn't, it's impossible to provide a version of DMS which is both easy and clean to install plus heavily configurable.
You can see where this is going. IMO we need a way to plug in configuration panels into Moodle. This, and some similar issues, have given birth to a vision of mine (I 've had it for quite some time now, but no time to implement it) of providing facilities for plug-in extensions to Moodle. Much like learning activities, only those would be providing additional core functionality. Let's tentatively call them components.
One aspect of this would be a "configure components" option in the administration panel, giving admins the power to change the way Moodle works. Each component, when installed, would be free to set up its own configuration pages inside that. Calendar problems solved.
Another aspect, not visible to users but I think very useful for programmers, would be placing "notification hooks" in Moodle. In plain English: when "something" happens (a new user account is created, a student enrols in a course, an activity is deleted... almost anything!), Moodle gives a chance to all installed components in turn to respond to the event, possibly by intervening and changing some aspect of what is taking place.
Example 1: If I want to provide "automatic" creation of user folders (or course folders, for that matter) in the DMS, I have to know when a new user has been created and take appropriate action. A notification hook would be ideal for this, which is currently done manually (by running a script).
Example 2: When a user is enrolled in a course, or when he is created, we might want to send him an email with "Welcome and basic instructions" (this in fact happens here at Surrey). Again, a notification hook and you 're set.
Example 3: I said above, "possibly by intervening". Here's a concrete example which you may find interesting. At the time a new user is created, he chooses a username. A "username sanitization" feature might be provided by a component that checks usernames before the user is created, and either strips/converts disallowed characters from them or blocks the process altogether. Of course that component could have its own configuration for the disallowed characters and the type of action it takes, thus removing the need to hack Moodle if you don't like the concept or the way it works.
Example 4: We can design components with "data push" strategies instead of "data pull". "Push" is loads better in any situation where data is written "rarely" but accessed "frequently" (recent activity speedup, anyone?), plus it allows us to write the "display recent activity" code without limiting it to specific types of activity it can display; in fact, without needing it to know anything about what "recent activity" is. The code would be distributed in the components; each would advertise its latest activity and all other components might choose to respond as they see fit.
Example 5 (advanced): Let's take this a bit further. We can allow each component, when installed, to define its own hooks. Other components may, knowing of its existence and the hooks it sets, choose to respond to them (this is in very broad terms, but think of integration and interoperability). Thus, component A and component B might be independent, but when installed at the same time they could still "work together" in some aspect.
I could probably go on for hours selling my case here, but by now everyone should be either convinced or asleep... so I shut up and wait for comments.
If there is positive feedback for this from the hard-core guys, I can start writing APIs so we can get more specific.
Jon
? By the way, what tools would you use for that? For our JISC project we will have to use 