Philip Quaife 22 Sept 05
Download from http://qs.co.nz/Download.html
US 27. 3. 2006: Not working: The requested URL /cgi-bin/autoKit.cgi was not found on this server.
PWQ May 12 06, autoKit is been superceeded by AutoExe and original demonstration server is no longer available.
Purpose A collection of cgi scripts that allow a web server to take a bare starkit file and add in platform-dependent (or other) extensions. It can generate a starpack or starkit file.
All files are mounted in vfs so no server side disk access is required.
Why?
I want to be able to distribute some of my applications and demos to prospective clients as demonstrations of my talent. The problem is that most of my application use one or more binary extensions.
For development I run wish with the programs picking up the extensions from my library directory and are shared among all applications. If I update an extension all applications can get the latest version (the principal point of shared libraries).
A starkit however is expected to contain all its resources inside the kit file itself (the principle point of a starkit).
When it comes to distributing a kit for use by other people, I have no choice but to create a special distribution kit that pulls in all my local resource and packages them up in the kit.
Since I don't know what platform they may be using I have to put shared libraries for all common platforms into the one kit (also a selling point of starkits).
The size and management of such compound kits is not tractable.
Hence the .kit files can be published without bundling the resources and can then be customised for the intended recipients platform.
Features
Why not starsync?
The sdx update mechanism is great, I love it. But it cannot selectivly update a kit based on platform dependencies. And it does not solve the problem of having to build special kits for distribution.
In the future I would like to be able to work the functionality into sdx for a community wide distributed archive. However there has to be a global need for this system beyond myself.
A Note on Tip#55 File 25 sept 05, I did not use the tip#55 format for the archive file meta destription file (called RELEASE in .kit file). I first appologise for not building apon the effort of others. Now the un-appology, I do not believe in writing code when you do not have to. Rather than making Tcl read a specific format, I use the format that Tcl can read directly ie:
set f [open /Kit/RELEASE]
array set meta [read $f]
close $fThere is much code to write , and the above principle (part of my QParadigm) applied to a whole application saves weeks of coding.
Operation overview
a. Local to web server.
b. Known list of server archives and archive server directories. a) mounts kit as -readonly + translucent.
b) searches for each dependency trying OS+CPU, OS-only, CPU-only, and finally platform independent file names.
c) If resource is remote it is fetched via http into in memory vfs.
d) if gziped it is unzipped.
e) if it is a .zip file it is mounted.
f) if it is a .kit file it is 'read' into memory and then mounted.
g) all specified files are copied into the application kit file.
h) if starpack requested, it searches local server and then list of known repositories for runtime:
currently qsolutions and then equi4
i) downloads , gunzips runtime, mounts runtime kit and copies into application kit.
j) sends runtime + starkit or just starkit to client.
Comments
Very cool - I did something similar which I describe here:
http://www.dedasys.com/articles/customized_downloads.html
Fascinating stuff Philip - parallels some stuff I've considered doing but it goes way further. Great work! - stevel
CL echoes the enthusiasm of Steve and David, and begins to muse whether Tcl download sites should become more dynamic, with executables delivered just-in-time ...