ObjectOrientedTWikiPluginSystem

This is an EdinburghRelease idea

Now that there are a couple of pluggable implementations of core functionality (HTPasswd, RcsStore, TemplateLogin, and soon TWikiUserMapping) I'd like to change the mechanism we use to do this, to allow OO-Plugins to tell configure that they are an implementation class for one (or more) of these Core interfaces, thus allowing the user to select the implementation they want from there.

This would make TWikiCore an over-rideable set of base implementations, which plugins would either be able to totally replace, or extend through the perl object model.

for eg

• I would move all my JoomlaSupport code from JoomlaLogin.pm, JoomlaUserPassword.pm and JoomlaUserMapping.pm into one plugin, which I would select in configure as the implementations classes for Login, Password and UserMapping.
• I could replace Render.pm with a totally experimental Render-er through a plugin

Unlike cgiwiki and kwiki, we would not be forcing users that want to try out an implementation module to write (admittedly trivial) code, they just install the plugin, and use the configure script.

on a related Note: we also need OptionalConfigureOptions and ConfigureDependencies

Benefits:

1. simplify the distribution of new implementations
2. FightTheFlab
3. make it more obvious to people that want to implement things like LDAPUserMapping where they can make a lasting change
4. simplifies the upgrade burden of customised core functions - just over-ride the function you need to change.

-- SvenDowideit - 15 Feb 2006

Instead of paralyzing in analysis, I propose a way to "experiment" the "pluggable" system:

1. Choose an aspect of TWiki (it must be atomic but complete).
2. Extract the "whole" code for that aspect into a "Plugin", even if it need to call directly into the core, and add all the necessary handlers to call the functionality.
3. Test that everything works as expected.
4. Create an alternative implementation (that could be a small variation of the original).
5. Test that everything works as expected.

After the second step, it should be obvious which are the difficulties of making a "pluggable" version of the aspect, and the necessary hooks are identified.

-- RafaelAlvarez - 15 Feb 2006

no, no this is exactly not what I was suggesting

rather than moveing the whole shebang into a plugin, I'm thinking we just add a registration and object initialisation system to twiki that enables it to instantiate a class in a Plugin instead of the one in the core. Thus you avoid the upfront struggle to pre-determine what should be pluggable!

-- SvenDowideit - 15 Feb 2006

Moving the whole shebang into a plugin is not what I was suggesting

Actually, I forgot to specify one more step. Once the plugin is working, every "hook" is in place, and there are two implementations of the same aspect, is time to abstract the interface for the aspect, and change the plugins to be "implementations of the interface". After that, with either a registration or discovery mechanism those implementations would appear "automagically" in configure so the user can choose which one to use (much like password management and store implementation is selected)

hmm.. this is one of those areas where code will explain the idea a lot better than words.

-- RafaelAlvarez - 16 Feb 2006

I think you have to be careful about using the word "plugin", which is loaded with TWiki preconceptions.

Rafael, in a sense I already performed the "experiment" with the selectable implementations of the Login Manager and Password Manager. I would have done the same with the Store Manager, but I thought I had scared people enough already by that point

Note that implementations really need to be context sensitive. i.e. the store implementation should be per-web.

The only real issue with the current implementation of the managers is that the configure interface has to be explicitly told what subclasses are available. That's simply because I was too lazy to work out a discovery scheme.

Sven, you say "instantiate a class in a plugin instead of in the core" and suggest your thereby "avoid the upfront struggle to pre-determine what should be pluggable". No, I don't think you do; TWiki has already been split down into objects, and that was exactly the sort of pre-determination you want to avoid. You also can't avoid the fact that encapsulation is incomplete, and much more is known about the internals of objects than you would like. IMHO upfront work extracting interfaces is unavoidable and desireable.

-- CrawfordCurrie - 16 Feb 2006