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.

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!

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.

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.