Conceptually, a Wikit is a searchable collection of inter-referential pages entered in a markup language and displayable/editable by several user interfaces.

Wikit functionality falls into four general and orthogonal categories:

1. Content and Title Keyword Search

As snitvfs points out, keyword and title keyword search functionality is directly supported by metakit views, using the mk::select facility -keyword. This is also provided by mkvfs as a special case of its pass-through to metakit select.

2. Titles: Linkage between pages

Wikit provides the ability to reference pages in a [keyword] form within markup, where the keyword maps to a page title.

This is implemented by a metakit view mapping referring->referenced pages, which is updated by inspection of pages upon creation, editing and re-titling. mkvfs could store titles as a file attribute and make them searchable as for content.

3. Markup Language with display conversions

Wikit has a markup language described in Formatting Rules. It is re-parsed then converted on-the-fly to several different user interface formats, specifically HTML and Tk Text widget commands.

Absent a page-typing system, only one kind of markup is supported. Given a more general page store, content typing could be used to store and deliver arbitrary file types. mkvfs can be generalised to support arbitrary meta-data such as mime-type by means of file attribute.

Different markups would be possible, as would

4. User Interfaces - Tk GUI and HTTP/HTML

5. Revision History

This could be provided by a versioning virtual filesystem

6. Image Storage

Images can be stored in the Wikit, details of this mechanism are unclear to the author.

7. User and Modification Control

Wikit provides rudimentary modification control by specifying a hard-coded list of page numbers which may only be edited via the Tk GUI, or from localhost by HTTP. mkvfs supports unix access and ownership semantics, with user identification in a separate module.

- CMcC 20040726

---

Re 2: yes, or even make the title the file name altogether (encoding some chars as %xx perhaps, as in urls). -- jcw

Re Re 2: difficulty of a technical nature: vfs.c doesn't support a file rename hook, so tcl fs core simulates it by opening the src and dest, fcopying src to dest, closing both then deleting src. Not only is this relatively inefficient, but it means there's no way to know when a title is changed under the 'file name implements title' scheme, so no way to hook into the necessary link update logic. -- CMcC

Re 3: wikit used to have a "type" tag, but it was never used much. I decided to remove it and go for headers in each page instead. So when wiki pages are saved outside the system they have a few extra lines, see [1] for example. That could easily support more types, even a content-type / mime type. -- jcw

Re Re 3: mkvfs allows the user to specify directory layout. Every element in the directory layout becomes a file attribute, so it's quite extensible. -- CMcC

Re 6: see Adding images to local mode wikis. It's tricky, but it's supported on local mode accesses, which is useful in embedded help, for example. For CGI mode, it might not be very effective (exec overhead), and for caching and embedded httpd access the reason it is not yet implemented is more one of how to define how to refer to the data and where to cache it. Public http use also needs to address abuse, so for now, images still are just a partial hack.

Trying to untangle / modularize the things a wiki does is a good idea, IMO. Page markup and hyperlinks and searching really make a wiki a wiki, but with more modularity one could vary trade-offs a bit more. -jcw

---