Real Time Wiki Design
Real Time Wiki DesignHere's an idea for a RealTimeWikiDesign. Yes, I really mean RealTime and no, there's no versioning problem with this design when multiple people edit the same page simultaneously (i.e. a MultitaneousApplication). There are some small restrictions. Please shoot it down if you can. -- LeonardNorrgard
The interesting part is in the "How it works" section below.
The main idea is that several people can edit the same page simultaneously as long as they are editing different lines. You will select the lines that you want to edit and say "edit this", and then will be able to change them. You'll be able to see other people editing the page. This can't be done with a normal web browser, you'll have to have a special client, perhaps an applet.
Skip to the next section ("How it works") if you're short of time. For reasons that will be obvious you will need a recent JavaPlugin? in your browser in order to edit with the RealTimeWikiClient?, or you can run the RealTimeWikiClient? as a standalone application if you wish. Either way, it's a one-click install using JavaWebStart and the client is cached locally with auto client updates if necessary (these are standard features of JavaWebStart).
If you don't want to edit, an ordinary browser is perfectly OK as a client. You miss out on things like "wiki edits since I last looked", which the Java client can show you easily.
On the server side it should be quite possible to continue using cgi, if need be, but with a new implementation. A database is needed, either MySql (now with transactions) or the SleepycatDatabase? should do. Both are free for non commercial use.
How it works
The central idea in the design is an editblock. On the server, an editblock has an editblockID number, a PageID and a Span (start and end position on the page, could be the same position), an owner and a time to live. When someone saves their editblock, the server updates the Spans for all other open editblocks, but only locally on the server. The clients that are editing the other editblocks don't care, they're using the ID only. A consequence of this design is that you can't acquire an editblock that spans someone else's open editblock. That should be OK.
When clients get around to saving, the server looks up their editblock using the ID, inserts the text in the (possibly updated) span and updates all other open editblocks on that page. The lifespan of the editblock is then over.
TO INSERT NEW TEXT on a certain position on a page, the best thing to do is to click there and give the command to open an editblock. The request goes off to the server and it will succeed unless someone else has very recently acquired an editblock that spans the position you clicked on - you're given an editblock ID. Once you're given an editblock, you can freely edit within it - change it, delete it or add to it. Edits are not shown to others until you're done, that is until you save your editblock.
You can concurrently hold multiple editblocks on the same page or on multiple pages The ones you forget about will time out and self-die.
TO MODIFY TEXT, you first select the text and then ask for the editblock, then proceed as for inserting new text. If you just want to insert new text anywhere on the page don't select text first, as this restricts others from editing that text span.
The new server will not be backward compatible with the current (or it could be, but that would mean people would get editblocks to whole pages which is counterproductive). This means that if RealTimeWiki is accepted and implemented, the current wiki contents would have to be inserted in order to maintain momentum and the current wiki shut down.
BUT WHAT IF someone has already edited the page I loaded a moment ago and intend to edit now, won't the editblock span that my client sends to the server be wrong? Don't worry - pages carry a version number. The version number of the page you're looking at is sent along with your request for an editblock. If there are newer versions of that page you will get the latest update before editing.
Consequences
Negative consequences:
Oh well, so it's not quite RealTime. Near enough ;-) -- LeonardNorrgard
I've done this for one client. They were using the Wiki for project documentation and were afraid of accidently losing information under simultaneous edits. I used the basic Wiki code from Ward and modified it to commit to a CVS system (CVS is a source code control system). If two people edited the same page on different lines, CVS would automatically handle the merging. If there was a conflict, CVS would report it and the second submitter was taken to a conflict resolution page where they could manually resolve the problem. A side benefit of using CVS was that we could pull up old revisions of pages very easily. I've glossed over some of the details, but the basic system worked well. -- JimWeirich
DoTheSimplestThingThatCouldPossiblyWork:
I'm suggesting doing something like CVS does: Do a "diff" and merge the changes if they're on different lines. If both people (or "N" people) added changes to the end, then just concatenate all new lines to the end, in the order posted.
But, on the other hand, applying XP principles (DoTheSimplestThingThatCouldPossiblyWork), just telling people that there's been a conflict seems to be enough: They can go back to the edit page, recover their edits, and merge them in themselves. I've done this several times, and it really isn't a very big deal. (And it discourages people from making excessively complex changes all in one shot. ;-)
-- JeffGrigg
DoTheSimplestThingThatCouldPossiblyWork and provides the intended features. I think DTSTTCPW is too often read as just Do The Simplest Thing. I like the usage of a versioning system though CVS has its own concurrency problems - you will not always be able to check in. This can probably be resolved by having the WikiEngine retry until it succeeds. -- LN
Thanks for the really good explanation/illustration of the concept, DoTheSimplestThingThatCouldPossiblyWork. Now I get it. -- BryanHoover
WebMacroWiki is a Java implementation of a WikiEngine built on top of WebMacro. It should serve as a good basis for the server end. -- LN
...Avoid CantOpenWikiDbForUpdate errors...' I think this might turn out as nonsense. AFAIK nobody has verified the reason for this problem and I would assume that it is a general performance problem under heavy use (perhaps # of connections) and might have nothing to do with simultaneous edits of single pages. -- HelmutLeitner
See WardCunningham's comment on CantOpenWikiDbForUpdate.
To avoid scalability problems with relying on a central server for notifying all interested clients in updates to the wiki, I suggest building the update functionality on top of a dedicate InternetRelayChat network. InternetRelayChat is a time-tested technology, and an open internet standard (see RFC 1459). On the dedicated IRC network, one would create a channel, say #wikisitename that is writable by that wiki site. Interested clients would subscribe to that channel, as well as channels for other wiki sites they are interested in following. The update message would be standardized so that many different clients could be written and used interchangeably. Distributed realtime Wiki, anyone? -- LeonardNorrgard
If the edits are small enough I can't see much motivation for notification and locking. So why not send tiny edits to the wiki (eg every 64 chars changed, or explicit commit, sends a message). Each client submits diffs, and gets back a sequence number indicating the page version now. If your write fails (because of a sequence no mismatch), the server gives back the client the diff to fix their copy of the page. This does not require any structural changes to the wiki other than adding cvs support. (nb the only way this is different from similar cvs suggestions above is that I am suggesting the 'editor' sends bundles of changes as you type, which is real time enough)
We might be solving different problems here. The 'problem' that would be solved by IRC is providing (1) a near-realtime list in the client showing pages with recent changes and recent edits. (2) The possibility to see the edits of other people show up on the page you're currently editing, without either party being able to disturb the editing of the contrahents (within the timeout period of the editingblock). -- LN
There was a wiki-like tool I saw a couple of years back where you could type anything on a shared whiteboard and it would slowly fade out; it was an interesting way of conversing. You might consider something like this in a shared editor - other people's recent edits appear as a different background colour which slowly fades to white. This would give you a hint of which bits to avoid editing, without adding locks of any kind. An edit conflict (i.e., a change you made which cannot be committed) could be shown up in yet another colour. An alternative to background colours could be something like the GoldBar used on the Clublet wiki engine.
Also see GoogleDocs? for CollaborativeEditing.
EditText of this page
(last edited October 2, 2008)
or FindPage with title or text search