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 [http://mini.net/tclhist/12090] 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]