item2
Next»

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.5 - Self updating Starkits

As we have seen, one of the key benefits of Starkits is that their internal VFS can be modified at run-time - they can even be self-modifying and self-updating. There is no risk of an application modifying itself and accidently damaging the file, because Metakit supports transactions. Even a power failure will not damage a Starkit, it will simply revert to a previously committed state (no repair is ever needed: this is fully automatic).

This can be used to make a Starkit self-updating- so it can update itself when a later version is available.

This can be as simple as replacing files within the VFS, or it could be a more sophisticated scheme such as one based on an incremental file transfer algorithm (e.g. rsync).

Another interesting consequence of Starkits being updatable is deployment over various media. For some time now Starkits have been used in applications where some part (and sometimes all) of the application scripts were distributed over a network in a client-server configuration at run time.

Taken to extremes, an application can be deployed as a small "placeholder", which on first starting (after installation) simply downloads all the necessary scripts, saving them locally inside the Starkit for subsequent use. One commercial application uses this approach to provide a user interface that evolves over time - based on the user interaction - but with no involvement from the user apart from establishing a network connection.

see also

Starkit Home Page

Tclkit Home Page

Metakit Home Page

SDX Utility

Wikit Home Page

Tclers' Wiki

Author's Website

Updated paper, by Steve Landers, as presented at Tcl/Tk 2002 conference - see also original PDF.

Papers & Presentations