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.

'''AutomaticLinkGeneration'''

Linking syntax is based on FreeLink''''''s, 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:''
* ''The owner can add names to the "Read ACL" list. (Or change it back to the default "*", meaning everyone can read the page).
* ''The owner can add names to the "Write ACL" list. (Or change it back to the default "*", meaning everyone can edit the page).
* ''The owner can add names to the "comments ACL" list. (If this is left as "*", then everyone can append comments to the bottom of the page, even if they don't have permission to edit the rest of the page).''
* ''The owner can set someone else to be the owner. (There can be only one owner.)''
''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.

	* ''Paragraphs'':
		* Do not need to be indented, nor separated with blank lines. Every line in the WikiMarkup is a new paragraph. Blank lines make blank paragraphs, implying extra vertical whitespace.
		* Leading whitespace at the beginning of a paragraph (line) is ignored.
	* ''Horizontal lines'': any line starting with four or more hyphens, as is traditional. The rest of the line is ignored. (mnemonic: resembles a line in itself)
	* ''Lists and Headings'':
		* One of !@#$%^ at the beginning of a line for a heading - h1..h6 respectively (mnemonic: shift-1..6 respectively)
		* <# on a line by itself to begin an ordered list. Similarly, < to begin an unordered list. > to close the current list. (Actually, just as long as they're at the beginning of a line; but the rest of the line is ignored.) (mnemonic: opening and closing brackets. Unordered - bulleted rather than numbered - lists are default.)
		* Each line (paragraph) becomes a list item.
		* All lists are closed before a "special line" (heading or horizontal line) and at the end of the document.
		* No definition lists (IME they are rarely used).
	* ''Emphasis'':
		* *This would be '''bold''' (<strong>)*
		* /This would be ''italicized'' (<em>)/
		* =This would be monospace (<tt>)=
		* "This would be quoted (<blockquote> or perhaps <cite>)"
		* Emphasis tags are interpreted as modes rather than nested pairs, and are unambigous. So /this *would/ work*.
		* Emphasis may not cross line boundaries (the tags are closed at the end of a line).

	* ''Escapes'':
		* ' (apostrophe) is the universal escape character
		* It prevents the next character from being interpreted in the usual way, allowing:
			* literal emphasis markers and square brackets (no linking)
			* lines starting with or consisting of multiple hyphens, list indicators (<#>), header indicators (!@#) or whitespace (which would normally be trimmed)
	* ''Links (AutomaticLinkGeneration)'':
		* Page names ("keys") consist of "atoms", which roughly correspond to words
		* A deliberate link is formed [like this]
		* Single words are also linked if they correspond to pre-existing pages. Multiple-word links to existing pages, or the creation of DanglingLinks for WantedPages, require the square brackets.
		* The | character may be used to exclude text within the link from consideration; every other |-delimited element within the []s is used
		* Atoms within a deliberate link are delimited by
			1. | characters
			1. spaces, following PhpWiki's lead
			1. lowercase-to-uppercase transitions (as on WardsWiki). This ensures backwards compatibility with other wikis.
		* Non-alphabetic characters other than | (notably ') are discarded in the link text.
		* Example: The atoms in [th'is|example|of|a|very comPl*ex|link] are "this", "of", "very", "com", "Plex".
		* When the "view" script is asked to serve a page, the following algorithm is used:
			* All atoms are extracted from the link text (query argument).
			* The extracted atoms are sorted by decreasing order of length, then ascending alphabetical order.
			* Atoms less than 3 letters long, as well as "and" and "the", are discarded from the end.
			* The case is changed to some consistent pattern when looking up the page data - probably all lowercase or something.
		* Thus the remaining text contains only the bit of the link that's really meaningful for distinguishing different page names. The point of all of this is to minimize the instance of duplicate pages for the same topic. On ZincWiki, a page like RefactorMercilessly would probably have a key like "merciless+refactor", and all of these would point to it:
			* R''''''efactorMerciless (since it's a single word)
			* M''''''ercilessRefactor
			* [refactor||merciless] (would show up as a single word)
			* [refactor merciless|ly]
			* [merciless|ly refactor|ed]
			* [merciless refactor|ing]
			* [|truly, |refactor|ing is a |merciless |mistress]
		* When the links are rendered, the | characters would be taken out of page text, but included verbatim in the query argument of the link.
		* External links will probably need some special handling, or else they'll be full of apostrophe-escapes. :\ Links to image files (.gif, .jpg, .jpe, .jpeg, .png) will be inlined, even if there is a query argument in the link. There would not be any special handling of ISBN numbers, probably.
		* I'm not yet sure how to handle InterWiki links.
	* ''HTML'':
		* As on WardsWiki, no HTML support would be included
		* <, & and > would be themselves, except for lists (see above).

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.

'''BackLink''''''s'''

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?''

'''RecentChanges'''

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:
	* Prevent edits from being saved in rapid succession (with a timeout of, say, 60 seconds between saves. This also insures against destroying a page by saving multiple garbage versions.)
	* Note the current version number when a user starts editing, so as to advise the user if another version has been saved in the meantime.
	* Provide functionality to QuickDiff any two versions of the page against each other.

'''HowToDeletePages'''

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

'''ChangeTitle'''

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.

'''PageList'''

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.

'''VisualTour'''

I have no plan to implement this.

----
CategoryWikiImplementation