Hi folks,
I'm planning on moderating a discussion on MediaWiki in the enterprise (businesses, not the starship) next week at Wikimania (Friday, 8/4), and I'm hoping to kick off a pre-discussion about that here. My motives aside, this conversation doesn't need to be about my session to be on topic...I'm interested in a general conversation about MediaWiki in the enterprise.
I should start off with a disclaimer to the core MediaWiki devs here: my knowledge is mainly based on 1.5, and my dev chops are a little rusty right now. You'll see some half-baked ideas below that I'm planning to, um, bake a little bit in the next week. I'm also planning on being around for at least some of Wednesday and all of Thursday of Hacking Days, so I'm happy to discuss then if asked.
Regardless of whether you're going to Wikimania or the session, I'd like to hear from you if you have thoughts on the subject. Specifically:
* Users: what sorts of things are you doing? * Developers: what are the most frequent feature requests from intranet users? What are the most annoying ones? Which are the best that haven't been implemented yet? * Propsective session attendees: I'm really interested in anything you have to say about what you hope to get out of the conversation.
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. * 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. * More robust read-access controls (and more granular access control in general). Oft requested, oft rejected. I'm interested in starting a conversation about what interfaces could be added to the code such that an ACL-maniac extension to MediaWiki could exist, without a big support burden on the core team. Before replying to this, please read Brion's reply to me from November, 2005 on this subject: http://permalink.gmane.org/gmane.org.wikimedia.mediawiki/8610 * New distribution mechanisms. There's already a Debian package for MediaWiki, I'm assuming there's an RPM out there. Does a PEAR distribution make sense? Does it make sense to package MediaWiki extensions as .deb/.rpm/PEAR thingies? * 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 * Training - it's often hard to get someone who is used to mailing around Word docs as attachments to use a wiki with its {{{random-adjective}}} syntax instead of WYSIWYG. How do folks deal with it?
So, that's just some top of my head ideas. Others?
Those are some of my thoughts for now. I'm hoping to get more organized as Friday draws closer.
For those interested in the session, the details are here: http://wikimania2006.wikimedia.org/wiki/Proceedings_talk:RL1
The talk page for the page above is a good discussion venue for items that aren't of general interest on this list.
Looking forward to hearing from you.
Thanks, Rob
Hi!!!!
- Users: what sorts of things are you doing?
Keeping stuff.
- Developers: what are the most frequent feature requests from
intranet users? What are the most annoying ones? Which are the best that haven't been implemented yet?
Once they get used to it - more integration with other processes happening.
- 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.
There're two authentication plugins. One is the AuthPlugin, another, specially crafted for intranets with single signon environments, is utilizing AutoAuthenticate hook.
- Authorization plugins - not much as of MediaWiki 1.5....I'm
guessing (e.g. LDAP group "admins" gets the "edit" capability on resource "MediaWiki: namespace") This is admittedly pretty fuzzy right now.
Actually single hook changed, now you can have 'advisory rules' - chain extensions, and instead of them having just to say "yes" or "no" for 'userCan', you can just say "I don't know".
- New distribution mechanisms. There's already a Debian package for
MediaWiki, I'm assuming there's an RPM out there. Does a PEAR distribution make sense? Does it make sense to package MediaWiki extensions as .deb/.rpm/PEAR thingies?
Well, easiest way to update mediawiki is 'svn up' anyway ;-)
Thanks, Rob
See you! ;-)
On Thu, 2006-07-27 at 09:06 +0300, Domas Mituzas wrote:
There're two authentication plugins. One is the AuthPlugin, another, specially crafted for intranets with single signon environments, is utilizing AutoAuthenticate hook.
That hook went away when the StubObject code was added by Tim in r15823. Was that on purpose?
Rob
Seems to be an unwanted side effect indeed, as single signon systems won't function no more, at least they won't be able to get automatically authenticated...
includes\Setup.php should probably be changed from: if( !is_object( $wgAuth ) ) { $wgAuth = new StubObject( 'wgAuth', 'AuthPlugin' ); }
to: if( !is_object( $wgAuth ) ) { $wgAuth = new StubObject( 'wgAuth', 'AuthPlugin' ); } if(! $wgCommandLineMode ) { wfRunHooks('AutoAuthenticate',array(&$wgUser)); }
Cheers, Peter.
On 8/3/06, Rob Lanphier robla@robla.net wrote:
On Thu, 2006-07-27 at 09:06 +0300, Domas Mituzas wrote:
There're two authentication plugins. One is the AuthPlugin, another, specially crafted for intranets with single signon environments, is utilizing AutoAuthenticate hook.
That hook went away when the StubObject code was added by Tim in r15823. Was that on purpose?
Rob
MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
"Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco."
"This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure."
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
On Thu, 2006-07-27 at 15:04 -0500, Lane, Ryan wrote:
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).
Does PHP do connection pooling with LDAP the same way it does connection pooling with SQL dbs? Seems that the hammering would occur if a new connection is initiated every time, but that things should be reasonably tame if it's treating it as a DB.
- 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.
Argh...looks like I forgot to finish that sentence. Yes, I meant to namedrop both Semantic MediaWiki and Wikidata. I probably got distracted at the point I was going to search for any other stuff that might fit the bill.
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.
Ah, right. I worked on something like that in my last gig. My understanding is that they plan to open source it, but I haven't seen anything on that yet.
You're right though. People will likely be more comfy without write acls if the only thing people can edit is a "draft" that's has to be approved before publication.
Rob
Does PHP do connection pooling with LDAP the same way it does
connection
pooling with SQL dbs? Seems that the hammering would occur if a new connection is initiated every time, but that things should be
reasonably
tame if it's treating it as a DB.
Connection pooling would help the connections per second (which of course would help quite a bit), but it wouldn't help the operations per second. I'm not so worried about the small to medium sized organizations, as the amount of requests wouldn't be high, but something like this could cause problems in large organizations.
I could be worried for nothing though, cause I have a 600mhz sparc server with 1 gig of ram that was able to do 80 ssl connections a second and 120 operations a second.
Ah, right. I worked on something like that in my last gig. My understanding is that they plan to open source it, but I haven't seen anything on that yet.
You're right though. People will likely be more comfy without write acls if the only thing people can edit is a "draft" that's has to be approved before publication.
There is an extension already out there for this functionality. It looks like my patches made it into the subversion server, so everything I mentioned should be possible now.
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/StableVersion /
V/r,
Ryan Lane
On Wed, Jul 26, 2006 at 10:22:53PM -0700, Rob Lanphier wrote:
- 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.
We've had good success using the Semantic Mediawiki extension for that at an ISP. It adds an extra level to the 'geek factor' so it's probably not that great in a non technical environment, but we're starting to get excellent results from it.
Tony
mediawiki-l@lists.wikimedia.org