contents

Introduction - 1

Background - 2

Deployment - 3

Starkits - 4

Tclkit - 5

Advanced topics - 6

Repositories - 7

Server apps - 8

Who uses this - 9

Examples - 10

Conclusion - 11

Acknowledgements

References

6.1 - Tclkit/Starkit architecture

As we have seen, Tclkit is nothing more Tcl/Tk, several extensions plus a small amount of startup code.

Tclkit consists of three parts:

• a large binary prefix - i.e. basically a wish executable statically linked with the above extensions (although on some platforms certain extensions may be dynamically loaded out of the Tclkit VFS)
• a Metakit dataset that contains all the scripted components of the above packages which is mounted using the Tcl VFS, allowing it to look like a normal filesystem directory.

A Starkit comprises

• a small Tcl prefix containing startup code
• a Metakit dataset containing all the files inside the Starkit.

When you “run” a Starkit or Starpack the underlying operating system launches the code contained in Tclkit’s large binary prefix.

• This, in turn, starts interpreting the small Tcl prefix in the Starkit, which performs the following steps:
• the small Tcl prefix asks the large binary prefix to re-open the Starkit, but as a Metakit database (it does this using the starkit package located in the Metakit database within Tclkit).
• the starkit package opens the Starkit to be run - using the TclVFS package (also stored in the Tclkit Metakit database) to "mount" that file,
• the starkit package then sources the main.tcl file in the Starkit’s VFS.

At this point main.tcl is in control and does whatever the application developer specified.

Although Tcl's Virtual File System accounts for most of the transparency of Starkits - there are a few VFS limitations that should be recognised:

• when loading a shared library, Tcl has to copy it out to a real file (and then clean up later)
• on Windows shared library clean up must happen on exit, but after serious errors this might not be done properly
• commands launched from exec and open pipe are not able to look inside VFS mounts
• on Windows, cursors can not be used from the VFS (make a temporary copy to a real file)
• startup can be slower, because scripts are stored in compressed form by default (but also note there are circumstances where startup may be faster, because many open/close calls are avoided)
• memory use is higher when the Starkits VFS is modified, because the underlying Metakit database collects changes between commits (the commit timer fires every 5 seconds by default)

see also

• Starkit Home Page

• Tclkit Home Page

• Metakit Home Page

• SDX Utility

• Wikit Home Page

• Tclers' Wiki

• Author's Website