Here's some things that I see as potential things to discuss:
- Authentication plugins. The authentication interface is very
good...it's gotten a fair workout from a number of angles
(particularly,
LDAP). Seems to be reasonably mature.
Thanks. I maintain the LDAP plugin, and I plan on adding a number of features in the future to make things easier, and more flexible. Eventually the plugin should even be usable as a full user backend for MediaWiki (that goal is probably pretty far in the future).
- Authorization plugins - not much as of MediaWiki 1.5....I'm
guessing
not much has changed. I'm planning to possibly discuss ways in which User.php could be overridden, extended, and/or stabilized as an extension interface. The idea would be a system where group
memberships
are stored in an external database, as well as capability assignments (e.g. LDAP group "admins" gets the "edit" capability on resource "MediaWiki: namespace") This is admittedly pretty fuzzy right now.
Actually, I'd like to have a feature like this completed in the next couple of releases for the LDAP plugin. I'm looking for a way to do this that won't kill my LDAP servers. If LDAP is your authorization store, it *could* be getting hit every page view, and caching authorization usually isn't a good idea (the most I'd be comfortable with would be caching for sessions, with short sessions).
- Structured data - I know that in my last job, there were several
things we used a wiki in lieu of a database for (e.g. we kept a list
of
new licensees of our technology on a wiki). It was nice, because we
had
the flexibility to add fields willy-nilly. So, it may be interesting
to
discuss the enterprise applicability of projects like
I remember seeing a couple things that were interesting in regards to this. One is Semantic Mediawiki, and the other was the wiki database extension that was mentioned in the wikitech list. I think there is also a sortable table extension.
Another extension that I think is very interesting for enterprise use is the stable version extension. This is a great way of avoiding part of the "we *need* ACLs" problem you can run into in enterprise environments.
The stable version extension allows you to have one or more stable versions of an article, and your current draft. You could have a group of "Document Custodians" from each department that are responsible for their department's documentation. Each document custodian could mark/unmark any particular version of an article as stable. You can state that any article not marked as stable is considered tainted.
I've recently started working on the stable version extension to implement some things that I found to be essential for the above process. So far I've only fixed a couple bugs and added a flag to only show stable versions to anonymous users (with another flag to allow them to also see the current draft). I haven't released everything back to Magnus, but most things aren't generic enough to be merged back in yet.
Using such a process ensures that users won't unknowingly view tainted documentation unless the documentation custodian wasn't doing his/her job. This doesn't solve the problem of all articles being viewable, but it helps keep the wiki openly editable, and is less restrictive than ACLs to collaboration.
V/r,
Ryan Lane