Next: , Previous: Copying, Up: Top

2 What is schtonk

Schtonk is an application wiki-kind of tool. It consists of a CGI-frontend (named g.tcl), a single-instance backend processor named backend.tcl doing most of the work and a database. The frontend and the processor are written in TCL and backend.tcl may also invoke additional TCL interpreters to evaluate TCL code contained in the pages that are being served using schtonk.


Image 1: Schtonk architechture at very general level

In Image 1 rough level break-down on schtonk moving parts is shown. End user is any http client, currently it needs to support https and authentication but it is possible1 to run schtonk without https or auth. As httpd only apache 2.x has been tried out but any httpd supporting CGI interface should do, as database only MySQL5 has been used, other versions of MySQL shoud work about out-of-the-box but if user wants to have something else, say postgres or oracle behind schtonk it is possible but does require some modifications2. Important data flows are numbered in Image1. Short description about those is
  1. Between http client and server obvious protocol is http and data format is html. Schtonk does support binary attachments to pages data format may really be anything. Client either refers to pages with URL or in addition to doing so, also may post a html form that will further cause some processing inside schtonk.
  2. Between web server and g.tcl the CGI interface is used, in practice the data content flowing there is the URL from http client and possible posted form data. After schtonk has finished processing the request, it returns here a complete HTML document.
  3. g.tcl is front-end processor of schtonk and g.tcl picks up relevant parts like id number of page user wanted to see and passes them to backend.tcl. backend.tcl does actual processing. After g.tcl is happy with the request (it does a lot of checking on formats and such) it generates a one-line digest of the request and sends that backend.tcl via TCP/IP socket. The socket is opened every time g.tcl is invoked e.g. once for each request. If there is any posted form-data then it is passed to backend.tcl as-it-is e.g. g.tcl does not try to modify it. backend.tcl writes back a HTML document that g.tcl does not alter, it just sends it back to httpd that sends it back to original client.
  4. between backend.tcl and database a database access library named mysqltcl is used. mysqltcl is TCL wrapper around MySQL client lib that in turn does the actual dirty work there. backend.tcl send SQL statements to database and gets data and error messages back.

Schtonk tries to implement a subset of MoinMoin wiki-syntax added with form-syntax stolen from JSP wiki, described in and the utterly useful table-format of double ||-marks like `|| column1 content || column2 content || etc ||' used at least by the fine folks at doing trac.

In schtonk the identifying thing for a page is a number, conveniently expressed in normal way to access schtonk pages: https://your.ser.ver/cgi-bin/schtonk/g.tcl?pageid=12345 where page with id 12345 is wanted ; this link is expressed in schtonk wiki syntax like this:

or if page_param is needed,


or if link name is needed

     [12345(possible_param_string) explanation of link pointing to page 12345]

Schtonk adds to this soup of 3 different wiki-syntaxes yet one more addition, namely embedding executable TCL code inside wikipages that backend.tcl will evaluate at server-side when the page-request is processed. This TCL code has access to database so making database-aware web-applications should be fairly quick, easy and debugging-nightmarish to do.


[1] But not encouraged

[2] By replacecing mysqltcl with oratcl or equivalent