MeatballWiki | RecentChanges | Random Page | Indices | Categories

This page is part of the CommunityProgrammableWiki discussion.

CommunityProgrammableWiki (UseMod fork)

At http://purl.net/net/cpw

[CpwWiki] is a wiki site with the capability for community members to modify the code through posting patches on the wiki. It is now working (to the best of my knowledge), (except for mod_cgi), but I need to add more comments to the Perl code for readability, and upgrade it to match UseMod 1.0. It should be possible to add most of the patches at UseMod:WikiPatches in a couple of minutes using the method described on [CpwWiki:SpwTutorial].

Update: I was running [CpwWiki] off my own computer for awhile, but I had to move to San Diego, so I moved to to SourceForge. Currently the software and the documentation are available at the above link, but it is not "live" (because I haven't had time to configure it to run on SourceForge's servers; there may be some issue with mod_cgi). Eventually, I plan to serve it off my computer again. -- BayleShanks


Right now (Nov 02), it is ready to run and looking for hosting.



DariusBacon?'s implementation. From his homepage, "A prototype webserver/Wiki in C. Makes its own code publically editable."


MuWebWeb seemed to be working on such a concept. Apparently MuWebWeb is dead, though.


"I am currently implementing a much more powerful version of this as WikiAsSourceControlRepository" -- SunirShah??

Implementation discussions

CommunityProgrammableWiki implementation

I like CommunityProgrammableWiki, although maybe UserProgrammableWiki? would incite more involvement. ReProgrammableWiki? may be the clearest for most people. Anything "Programmed" sounds like it's finished. There's also OpenCodeWiki?, or OpenTopWiki?, like a car with a visible engine. Finally you could emphasise it's changeability: EvolvingWiki?, UpgradableWiki?, DynamicWiki?. -- Anon

didn't see that comment until now. I agree, CommunityProgrammableWiki is better, I think I'll change. Thank you. -- BayleShanks

I'd like to suggest the following strategy in addition to using 'Safe' -

Every time someone edits the script to create a new variant, instead of replacing the existing wiki script with the new version, arrange to have it set itself up as a seperate wiki with its own database (which would be empty to start with).

Anybody who wants to use the new improved wiki then makes a copy of any pages he/she requires and puts them on the new wiki (possibly putting a PageRedirect on the old one, but that might require changes to the InterWiki system). If the new variant turns out to be buggy or contains malicious code people will quickly stop using it and revert back to using the old one.

The idea is that the variants would compete with each other as the WikiCommunity "votes with their feet" and continuously gravitates towards the "best" wiki available. Older wiki variants will still be around for a reasonable period for safety - but will gradually fall into disuse. Some procedure would presumably be needed to "retire" wikis that haven't been used in a given amount of time.

This still wouldn't make it impossible for a malicious user to wreak havoc, but it would make it a bit harder ;-)

-- DavidClaughton

That's a good idea. I was already planning to have the thing "forkable" by request (eventually), but you're right, maybe it should fork by default to some extent. Or at the least, forking will be useful for debugging.

-- BayleShanks

You can enable a "config page" for OddMuse wikis. The config page will be read and the code on it executed. Since you can override all functions using this mechanism, you can use it to "patch" the script. Since changes take immediate effect, and since there is no SafeBox? (ie. you can put code there that deletes the entire page database), only administrators may edit the config page.

-- AlexSchroeder


MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions