Hooks spec

(15:23:58) Marina: I have some suggestion for 2.6 that actually can work well with logging. At the moment we have events system which is one-way - the core notifies whoever wants to listen to it about something that happens and it is proposed to be used for logging. But how about we implement also "feature" or "hook" system where some code in core may be substituted or extended with other plugins.
(15:24:15) Marina: It is sort of mini-plugin system for all those small actions that don't need a separate plugin type. Examples where I can also see it useful - course search, global search, frontpage contents/redirection, etc. 
(15:24:38) Marina: Every time we need such sort of thing we introduce new $CFG variable and it's confusing and unmanageable
(15:24:58) Marina: There will be just a certain flexible interface and management page. Basically not so much from the core but plugins can go nuts.
(15:25:47) Martin Dougiamas: like wordpress and drupal?
(15:25:52) Marina: yes
(15:26:22) Martin Dougiamas: it would be good, but I don't quit understand what "extend" code from core means 
(15:26:28) Marina: I don't know about wordpress but in drupal it's not very manageable
(15:26:36) Marina: i.e. extend a form
(15:26:43) Marina: or contents of some page
(15:27:20) Martin Dougiamas: flexibility often is a tradeoff with usability 
(15:27:28) Martin Dougiamas: need some more fleshed out use cases with examples 
(15:28:00) Martin Dougiamas: I don't understand your examples above 
(15:28:49) Marina: we have quite primitive course search algorithm in core. Some other plugin may implement search with relevance, analysing tags, going through attached pdf files, etc
(15:29:06) Marina: the same with global search
(15:30:11) Marina: 3. We have $CFG->customfrontpageinclude for frontpage. It could be also hook/feature
(15:30:31) Marina: - these are all examples of features where only one alternative implementation can be chosen
(15:30:59) Martin Dougiamas: Usually we just make new plugin types 
(15:31:40) Marina: yes, or $CFG variables
(15:32:08) Marina: ok, I'll try to find more examples and write here
(15:32:15) Martin Dougiamas: With your model, would it basically just replace X lines of code (producing HTML) with a given function which produces it's own Y lines of HTML connecting to it's own code?
(15:32:38) Marina: it's one of the use cases
(15:32:45) Marina: but it does not have to be UI only
(15:33:17) Marina: in case of search - we ask plugin to give us list of courses and we go back to usual renderers to display them
(15:34:01) Martin Dougiamas: I like the idea if it doesn't complicate normal code too much, and the hooks across Moodle are sort of consistently managed 
(15:34:29) Marina: yes, that's the main idea - to have the centralised management
(15:34:52) Marina: so admin can see the list of all available hooks and for each enable/disable available implementations
(15:35:22) Marina: we just query each plugin or core on definitions and implementations it has during upgrade/install only
(15:35:34) Marina: and store the list in DB
(15:35:53) Marina: so each time the hook needs to be called we include only necessary file
(15:36:34) Marina: I can write some pre-spec in more details if there is an interest