rethinking the documentation wiki underpinnings
By joe
- 2 minutes read - 328 wordsWe updated the documentation server last week, and the wiki software, updated by the folks who write it, broke. I’ll try a few more things to fix it tomorrow/friday, but at some point I have to question my choice of wiki software. If the open source version breaks like this with a simple yum update, I don’t have much faith that the closed source variant with more features won’t break. So I am looking into foundation/large group led efforts. Primary contenders appear to be MediaWiki and XWiki. The latter is java based and the former is PHP based. Current software is PHP + Mono based. Can’t say I am too happy with it from the stability point of view. Easy to edit/use pages. Lots of good user control bits. Really crappy stability against updates. If I can’t resuscitate the old wiki in the next few days, we’ll see which of these we will use. Ease of editing/adding pages preferably with something like the fckedit or similar tool, is high on my list of important things. Ease of including additional things like images is very important. Ease of managing access is critical. We need to be able to do this at a user level. We should probably separate the user database from the wiki … maybe set up an LDAP server or something like that. XWiki is a java app, and that in my opinion, counts against it. I am never sure which jre to use, the ones Centos distributes (same as the Redhat ones) are broken with respect to a number of things. Add to this that java is not fast, by any stretch of the imagination. This is running on a VM, so we really do need it to not be needlessly slow. Gotta see what works though. Wish there was a good perl based system that had all the features I needed (there isn’t, I looked, and I don’t have time to work on writing one).