Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jdporter (36)

jdporter
  (email not shown publicly)
http://users.starpower.net/j.porter
Yahoo! ID: johndporter (Add User, Send Message)

Journal of jdporter (36)

Friday August 30, 2002
01:47 PM

wiki blows

[ #7423 ]

Don't get me wrong, wiki is a pretty cool idea. And in many ways, it's better than almost anything to which it might be reasonably compared.

But let's face it, wiki pretty much blows.

The problem? Scalability.

One of the other guys where I work, the chairman of a technical working group, decided to try using wiki as a collaboration tool as the group hammered out some revisions to a honking old document.

With only as few as three people working on the document -- some 100 different pages -- we had a problem with people overwriting each other's edits.

One part of the cause was a kind of social phenomenon: although there were around 100 pages in the wiki, at any given time only about 2 or 3 were actually of any interest to anyone. You know how it happens: one guy modifies a page; another guy checks to see what pages have been recently modified, notices that one, goes to check out what changed, and immediately wants to weigh in with his own changes. Get two guys doing that, and whammo! -- big headaches and discontent.

I'm now quite convinced that the wiki paradigm of editing whole web pages cannot reliably scale above exactly one author .

The real problem, of course, is locking. The lack thereof, that is.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

wiki blows 5 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • A set of friends used my Wiki clone (which supports rudimentary conflict avoidance) to hammer out a draft of their book. Their primary strategy for avoided conflicts was to be clear about who was working on what. They claim to have had few problems.

    But your point is basically correct. If everyone wants to have their hands on the same small set of documents at the same time, you're in for trouble.

  • I know that TWiki [twiki.org] locks the page while you're doing edits. People who try to edit the page while it's locked get a polite message saying that you're editing it. Locks expire after (IIRC) a configurable amount of time to prevent the "last-item-todo-before-vacation" phenomenon...
    • Well, yes, it's the classic "distributed exclusive lock" problem, which people have been working on for years. There are ways of dealing with it; problem is that any good solutions require some cooperation (i.e. running code) on the client side, and that's hard to do with www. Well, it's easy, in principle, since we do have javascript... but I haven't seen anybody try this. Alternatively, the necessary bits of code could be wetware -- but that has its own set of problems. :-)
  • For example MoinMoin will check to see if the page you're trying to submit has been changed by someone else during your edit cycle. But it's still annoying I guess.

    Can't say I relate that much though. We have a WikiWiki documenting our operations environment (a couple of sites, lots of hardware, lots of in house software, lots of third party software, etc, etc blahblah), with something like 400 pages.

    There is not much manual editing going on right now (we fill it with daily notes about the operation usin
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.