Zinc Wiki

ZincWiki is an implementation of WikiWiki in PerlLanguage, which I (KarlKnechtel) have just barely started on.

(This should probably be moved to my own wiki, as it reeks of WalledGarden. Unfortunately I don't have nearly enough of ZincWiki implemented yet to do that, and it seems a bit silly to install something else in the interim. Maybe I will just put up static HTML somewhere while I develop the first few bits.)

Last edited January 2004 - any further news?

(Nope, sorry. I've been rather busy with work that I might conceivably be paid for in the foreseeable future. Really must get into the habit of following through on personal projects... sometime...)

I have borrowed from WikiPrinciples to create a list of points which ZincWiki will have to address, and give some explanation of how they will be addressed.


Linking syntax is based on FreeLinks, using an expansion of the popular [] notation - see later section on the TextFormattingRules.

ContentEditableByAll; UserName

I plan to implement "permission groups" to add a layer of security. Pages could be "locked" as in PhpWiki; a locked page would specify a list of "groups" of people who could access it (set by the administrator), and anyone with any of those groups in their own list could access the page (read or write). Unlocked pages would be readable by (absolutely) anyone, and writable by anyone who bothered to sign in. (I'd prefer not to have anonymous edits, and not have to write the code to track IPs. Not sure if it'd even work on a free webhost anyway.) Account creation would be a simple matter of signing in with an available username and (optional) password; the admin could then assign privilege groups as desired.

That makes it sound like "the administrator" has to constantly review each and every new page created, and manually specify all the "groups" who have access to it. Maybe there's a more "scalable solution" that doesn't require "the administrator" to do quite so much work?

I think the "permission" implementation at WorldWideWiki (I think it's a WakkaWiki engine) is interesting. Hit the "Edit ACLs" button at the bottom of your homepage to see what I'm looking at. The person who creates a new page is automatically assigned "ownership" of that page. The owner has these special abilities that no other user has: Perhaps extending this to "groups" would be interesting. (EditHint: move this text to page WakkaWiki).

There's an interesting idea at Distributed Proofreaders http://www.pgdp.net/ : Second round projects are unavailable until you have proofed more than 50 first round pages. After 50 pages of first round proofing the second round projects will be unlocked for you. This seems like a cool SoftSecurity idea; how could we extend to wiki? Perhaps something like "Anyone can read any wiki page and create a UserName. People who have created a UserName are allowed to edit the SandBox and their own HomePage. People who have edited at least 2 pages are allowed to add comments to the bottom of any page. People who have commented at least 8 pages and have edited their UserName on at least 2 different days are allowed to edit any page."

TextFormattingRules, TextFormattingExtensions

There will probably not be any TextFormattingExtensions, for a while anyway.

This scheme has some definite advantages over the syntax used here, as should be expected for something completely redesigned. I've given consideration to how wiki syntax is used (including the relative frequency of various constructs) and what kind of text is presented.


I'm thinking of using something like EverythingTwo's "soft backlink" system, where a table of backlinks is assembled at the bottom of the page. When the user navigates from Wiki page X to page Y, a link to X is added to the table at the bottom of Y.

But how does the user get from page X to page Y unless that link is already on the page? How would new links be added?


I intend to implement this as a separate script, rather than a wiki page. It might also be able to provide an RSS feed.

RandomPage, TopTen, WantedPages, WantingPages

Like RecentChanges, these would not be implemented as a wiki page, but instead with a separate script (or argument to the main script; but lately I'm tending to appreciate WardCunningham's insight - having multiple cooperating scripts cuts down on parsing time and code complexity). I'm not sure I want to implement WantedPages or WantingPages.

PageHistory, EditConflictResolution, QuickDiff

Several versions of each page would be kept, with a HeuristicRule which "ages" old versions. That is, a frequently-edited page would be allowed to keep more old versions of the WikiSource. The code would not attempt to resolve edit conflicts directly, but would take the following measures to assist users in resolving them: HowToDeletePages

My big idea here: GarbageCollectedWiki?. (More later.)


ZincWiki pages would not store a title, but would appear titled according to the query argument. Taking the example from the link syntax description above: say I had the page "merciless+refactor". I could link to it as [refactor merciless|ly] and the page would appear titled "Refactor Mercilessly"; or I could link to it as [merciless refactor|ing] and it would appear as "Merciless Refactoring"; but the page content would be the same. A cute bit of PolyMorphism I think, and it eliminates (I'm pretty sure) the need for an aliasing system, which is one of the features I originally planned but quickly realized could be difficult to implement.


I might generate this during GarbageCollection.

LikePages, FindPage

The "Page not found" result from ZincWiki, I think, should have a LikePages listing as well as an option to edit (and thus create) the page. More useful that way; might catch someone's misspelled link on the previous page.

I need a good HeuristicRule for looking up pages and deciding the best matches. This is a case where I think I have to start out with the SimplestThingThatCouldPossiblyWork, and then somehow work out any necessary enhancements.


I have no plan to implement this.


View edit of January 29, 2007 or FindPage with title or text search