User:Nsh/temp/plan

Here are some ideas / grandious schemes I'm thinking about.

Real time Wiki

Brief

Load a wiki page and have changes to it sent via persistant http connection and diff(1)-like patches applied by javascript in real time

Mechanism

• Browser loads page with ">"update javascript function"<". After page loads, javascript function polls pseudo-"cgi script"
• cgi script tracks updates via RC or polls for dynamic pages (**see active-wiki**). when page change is detected, script requests a render of the new version
• script applies diff to new revision html versus old revision html
• each change in html is sent to browser over persistant http connect to update javascript function
• update javascript function parses the diff(1)-like patch and replaces the html and (if necessary) reloads the page

Notes

• Other possible update mechanisms:

- Java?

- Over p2p?

- Client-Server Wiki? (For Wikipedia CD/DVDs!)

• Applications:

- What you see is what you get Wiki editing with constantly rerendering wiki-text. Perhaps client rendering (md5 checking!)

- Wiki(pedia) walls: Have a selection (dynamically generated) of articles updating real-time (or playing time-lapse history!) in a collage which can be projected onto a large wall in say a public library. (WRITE MORE ON THIS: INTERACTIVE!!!)

- Have pause and playback toolbar in javascript (could be firefox extension!) Allow for reverting and talk page or editor messaging

Active Wiki

Brief

Wiki which is generated dynamically by programing (generic, or specifically in this context **see paradigm-wiki**) instead of static content which changes in discrete intervals. Open ended building block

Mechanism

Generator program pipes to wiki rendering engine (unless raw wiki code is requested) and displays as normal

Paradigm Wiki: (REVISE NAME)

Brief

Entirely new programing paradigm. Code modularity is enforced, but language is open. May be used to run external code in sandboxed by environment. Programs are dynamically generated prior to execution by creating the source code through the paradigm system. (MORE)

Mechanism

• Pick intended language(s). Must be able to take external arguements and generate text output.
• Allow editors to create and freely edit code segments (modules) which: Take arguments in accordance with argument system and either: Create data to be used as further variables, or: output text.
• Allow editors to create "program maps": Using only links (with meta-data to specify argument orders) to form any complete program using the existing community edited code segment "articles". Program maps return all outputed text from their module execution
• Program maps may be used to directly create **Active Wiki** pages, or may be included in other program maps. See *Wikivolution*

Notes

• Because code segments need only to read their arguments, access wiki articles (possibly), and provide output arguments or text they can be easily sandboxed and run in parallel (threads?).
• Code segments should be able to make internal variables globally visible until the end of their execution or the end of the program map.
• Advanced code segments, such as those which will constitute edit-segment compilation maps, will need to access article history meta-data. This could be done (rather hackishly) by allowing the code segments access all revisions of articles, it might be easier to have an external program which provides history data. See **history analyser**
• Program maps could be called from otherwise static wikitext like PHP from HTML.
• With a co-operatively designed inter-wiki directory (system? (p2p)) wiki's could call maps from external sites creating an even larger sphere of mutual improvement, idea development and code reuse.
• Allow for (read: ENCOURAGE) easy and extensive commenting of the code segments - ideally to the point where even non-programer editors can understand the code (hence modularity is very important, do one task well!). Perhaps make code segments normal wiki, but with code in special tags.

Wikivolution

Brief

Idea for an intelligent learning article generation system implimented in Paradigm Wiki.

Mechanism

• Multiple program maps make guesses for whether an article edit will be reverted in some time period.
• A master program map tracks these guesses and checks their accuracies.
• The component maps are informed if they guessed correctly or not and can update their constituent algorithms accordingly.
• A "food scarcity" algorithm determines which component maps are "fed" more or less edits per unit time.
• Successful maps will be fed more and thus recieve more feedback than crap ones, but if successful maps stop improving, the feeding division tends back to equal.
• The most successful map at any time (determined by an editable alrogithm (map) as is everything) can be used for outward facing wikis with high vandalism, etc. Fallback system could be implimented where second most successful takes over if #1 has algo glitch.

History Analyser

Brief

Creates data from an articles history tables.

Mechanism

• Data contains all text that has ever been included in article (unimportant text can be ommited for memory/space reasons).
• Smallest discrete text string is the largest continuous string which hasn't appeared in part.
• Data entries define contatenations of discrete strings which have appeared.
• Each entry has the following data:

- Originating editor

- Total time it appeared in article, broken into each continuous segment

- Editor(s) who have commited an edit with this string

- Edit summaries of edits which have added or removed the string

Applications

• Produce history maps (like history-flow tool). Shows article as strata of discrete strings over time, each string is given a different colour. (Strings produced by the same author may be all similarly coloured for clarity, etc).
• For wikivolution-style Active Wiki program maps which need to consider whether the addition or removal of discrete strings is likely to be accepted or reverted.

PROOF OF CONCEPT PLAN

Create PoC(s) to demonstrate:

1. Real time Wiki difficulty: easyish
2. Active Wiki difficulty: easy
3. Paradigm Wiki difficulty: hardish
4. Wikivolution difficulty: " + hard
5. History Analyser difficulty: medium

1

• (a) CGI script: perl/php/whatever. Uses some feed to track recent changes for article being "streamed". Asks for new wikitext (or diff! impliment diff raw output in index.php!). Uses some renderer (own mediawiki or external) to create html diff. Sends diff to javascript function

• (b) Javascript function: Wrapper around page. Loads page and keeps connection open waiting for updates. Applies update "patches" as they appear.