Purpose: document tools and techniques for creating persistent state in Tcl and Tk applications. By persistent state, I mean the ability to have a Tcl/Tk application, at start up, initialize all its variables, widgets, etc. to the value they had at the time of last termination.
This will require the storing of variables in a form they can be reset, recognizing all widgets, their configs and values, etc.
Metakit is one tool.
Relational databases (postgresql, for example) do a good job of keeping track of state. They have been perfected for just such a task...
(1) I'd say only a "persistable" state should be made persistent, i.e. where open files have been closed before (they will be on program termination anyway). To make sure the file is not modified in the meantime, it has to be put on read-only - but even that can be reset by the owner (or root)...RS
(2) Here the proc command would have to be overloaded to save its name argument immediately after each call, so at "pickling" time (I think that's how they call it in Python) you know which procs have been changed. But that can be countered by redefining the proc command. RS
28Sep02. Little known fact -- e4Graph's [L1 ] Tcl binding allows you to define additional methods on a node in Tcl, which are essentially stored procedures. This allows you to store a whole Tcl program in an e4Graph storage. The syntax is very simple:
% $node method foo {a b} {list $a $b [expr $a + $b]}
% $node call foo 34 45
==> 34 45 89For more details see the e4Graph page.
28sep02 jcw - I would like to distinguish between dumping and reloading state, and true persistent apps - i.e. ones that conceptually reside in storage, but just happen to be active at times. Quite an important difference: the latter scales to any size datasets, the former has long startup and exit times once apps/datasets grow. Squeak is an example of the latter btw - though not quite using the database perspective I have in mind (with commit/rollback and relational operations). Apple's HyperCard was another example.
28Sep02 Jacob Levy - Correct, the Tcl binding of e4Graph is a true persistent application. I will post some data here soon to show that its performance quite competitive.
See Dumping interpreter state for a quick shot that does global variables, procs, and interp aliases.