Geek: Wikis and Locking
Here’s the problem: I’ve built most of a wiki. However, I need to figure out how to implement locking. That is, I don’t want people’s changes overwritten by other people’s changes. This is easy enough, except I’d also like some kind of real-time collaborative capability, which makes things more tricky. Here’s some requirements:
- It must not destroy any unseen changes
- It needs to have a pretty quick turnaround (i.e. 30 seconds wouldn’t be out-of-the-ordinary as far as close-to-real-time goes)
- It needs to work without any quirks on the user side. That’d just be a pain. (Okay, and I needed a third point. Two points just looks silly)
The reason for these is that some of us need to collaborate on what eventually will be fixed documents. It’s the sort of thing dialog is needed for.
Ultimately I’d prefer to just use something like SubEthaEdit, but we’re not all gonna be on Macs all the time. Of course, the other option is just that we IM or something, and one person “takes minutes,” and we email back and forth or something. Suggestions please…
Comment by Angus • Thu 22 Jul 04, 11:21 pm #
Hmm, a web-based SubEthaEdit using the rich-text editing capabilities of Mozilla/IE and XMLHttpRequest polling of a server-side multiuser aggregation script could be a killer app.
(BTW: Your WordPress install is still “teh sukc”. Can you pleaaase turn off ‘required’ email addresses on posts, as typing in nospam@example.com is boring me rapidly? And hack it to give you back a copy of what you post on the “fill in more fields you fool” page after submission? Thanks ;).
Back on topic — why not just install MediaWiki, which powers Wikipedia? It’s free/Free, supposedly cool, and like most good Wikis runs off a revision control system so that input collisions don’t matter too much…
Comment by Matt • Fri 23 Jul 04, 12:12 am #
*sigh* okay, email req’d is turned off.
And I looked at various other wikis. The biggest problem is that none of the decent ones support real users, of the no-access-if-you’re-not-logged-in kind, or really of the decently flexible permissions inside the system. I’ve got that happening, I just need a way to lock/version control stuff.
Also, I far prefer running something lightweight (less problems), and the fact that I wrote it makes it *way* easier to customise/troubleshoot.
Comment by Matt • Fri 23 Jul 04, 1:16 am #
Ok, so I had a look at MediaWiki, which seems to be the best so far. However, there’s still a few problems.
1. There’s no fine grained user control. The only access control is “make this page only editable by admins,â€? where I need to be able to make pages non-readable to users under a certain rank etc. Also, there’s no control over who registers.
2. It’s definitely not lightweight. It looks like it keeps near indefinite changes; I don’t have that much server space.
3. It’s gonna be a pain in the butt to get it looking how I want it.
Those gripes over, it’s still a possibility—except that we’re talking multiple installs to get decent permissions happening.
Comment by Angus • Fri 23 Jul 04, 4:44 pm #
Woo, yay, commenting is now improved :).
Well, if you have something half-written already, you might as well polish it off the way you like it. Perhaps there’s a market niche for a lightweight non-sucky wiki!
Comment by brehaut • Mon 26 Jul 04, 9:50 am #
So anyway, i forget who i was discussing this with, might have been gus.
Theres one problem with locking: stateless webpages :P
yuck. anyway, someone (person X) may start working on a page at 10:00. half an hour later, they are done, so they repost (10:30). no doubt you are aware that if someone (person Y) was to make changes in this time, the will appear for 15 - 20 mins before getting blatted by X’s mods.
An easy solution:
database table locks {userid (references user table), pageid (PK, references pages table), timestamp}. when someone requests a page editing form, you create a lock in that that table. if there is an existing lock, check its time-stamp, if its more than say, 2 hours old, remove that lock and let the new user get the lock. And on saving of changes, check the user against uid and on match, remove the lock and actually save those changes.
that will work. unfortunately, it has the problem that if someone wants to make some other changes to that page then they are out of luck till and update. Network problems could also cause grief if someone forgets to release their lock (forgeetting to save or cancel).
A work-around for this problem: locks are per section of a page. I think this is how some of the larger systems do it. you edit (and lock) only sub parts of a page. personally i can only see this being annoying, but if you want true locking it probably the most flexible approach.
Alternatively, instead of locking (or perhaps with optional locking) if you let any user edit a page, and then save, but you use the tool diff to work out what changes they have made based on what they were editing from, and if the page that they have been working on was saved in between times, then you just give them a merge page. repeat till all conflicts are resolved. This is basicly the CVS approach. Solves all the problems with locking, and generally things will run smoother. on the other hand, you could find yourself fighting with other users by having to do a few merges (theoretically, not sure if it would happen considering the number of users of this wiki). I suspect it could also be a pain in the arse.
Thats basicly it i think. Any thoughts?
Comment by brehaut • Mon 26 Jul 04, 9:57 am #
web-based subethaedit:
umm, i dont even want to _think_ about how hard this would be to implement. firstly, to do it effectively you would need to avoid polling the server as much as possible (hard with HTTP, although with XMLHttpRequest its quite possible using its async handlers). secondly, you want to have an stateful app running as(in?) the server probably - the constant page calls by PHP scripts would hurt your response times. Incidentally i think sending XML would be a mistake for communicating between server and client. regexp and plain text would be much faster to process, and i dont know if you’d need much more.
and the single hardest thing would be the concurrency control (oh, sure it seems easy in your head, but don’t come running looking for help to debug the mess that results :P). yurk.
while its a cool idea (and theoretically possible) i dont know if the tech is there to support it yet (mostly in the communication protocols and stuff - HTTP level stuff for that sort of comunications is not flash i think, alot of unnecissary overhead).