Rob Lanphier wrote:
If someone were to get gung-ho about implementing access control measures in MediaWiki that go way beyond the immediate needs of Wikipedia, would you prefer that that person/group:
A. Submit patches for inclusion in mainline MediaWiki B. Submit patches to extend the MediaWiki core to allow for a security layer C. Submit patches to modularize/wrap some MediaWiki components (e.g. the parser) in a way that they can be used as libraries for an otherwise forked/rewritten wiki product D. Fork MediaWiki
The main thing is that we (at least I ;) don't want to have to maintain code that's totally useless to us, and a security layer adds maintenance obligations to that useless-to-us code (if there's a hole, we have to patch it and issue new releases, and if it exists people are more likely to want to rely on it, increasing the weight of the obligation). Thus my knee-jerk reaction is D; if somebody wants to maintain such a beast, let them.
B. is possibly appropriate though; I hacked in the AuthPlugin so people could work on things like the LDAP and other custom authentication interop things separately from the main code, without adding too much to the core code complexity (and others have helped improve it, and it could probably still use improvement ;)
It _might_ make sense to have a similar access control interface which can then be plugged in, though I'm not sure how much plugging would really need to be done if the infrastructure for all the plug points would actually be there.
Jej wrote:
So my choice would be a fifth... E. To write some specifications from needs, abstract the problem, and start a new project :) Any ideas ?!...
Specs and abstractions are always nice to have before one starts. ;)
-- brion vibber (brion @ pobox.com)