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