Starkits are about packaging, "wrapping" the pieces that comprise an application or a library so they can be deployed and used as a single file.
Occasionally, people ask what the point is of putting a single script into a starkit:
A digression: wrapping vs. updates
The "packages" argument has two sides to it. On the one hand, developers tend to create a world they work in, where all the tools are set up and configured to be as convenient as useful and where all packages are placed in an on-disk repository. On the other hand, there is the issue of deployment, where that development environment is absent.
The advantages cited for the first, more widespread and traditional, perspective are that it is far easier to maintain revisions and upgrades to each of the different packages used by an application, and that it is more efficient in disk space used (and memory, in the cased of shared libs).
IMO, both arguments need to be reviewed in the light of today's technologies and trends:
Easier updates - it is of course much simpler to update everything through as single copy of a package. But this misses the point completely IMO: in practice, the last thing you want as developer is breaking stuff. This is so common with frequent updates and the not-always-perfect-QC of OSS software, that in my experience, I tend to delay updates of a package, unless there is a known problem, and a resolution is needed. The reality is that I tend to go out of my way to make sure nothing ever changes in a project once it is past the earliest development stages.
There is an analogy which applies here, IMO: when you buy a car, you don't go out and replace it with an upgrade whenever a new model comes out. Our streets are filled with cars which all have different "version numbers". To put it differently: if it ain't broken, don't fix it. I'd like to extend that to: if it's only broken in ways you don't care that much about, don't fix it. The urge to update to the latest revision, even with lower-volume software where mishaps and imperfections are far more common and long-lived, is a bad one. We techies tend to update because we can, losing any benefits that come from keeping a software solution stable, known, and dependable (yes, even in its weaknesses).
Disk space - once a software solution has been created and tested, it needs to be "sealed" in some way, to reduce the brittleness which inevitably comes with development (try flipping one random bit in a project, and see how often such a change turns a working system into one which catastrophically fails). A copy of everything needed is the simplest possible way to do so, it helps create a new state with an identity and by being a single file, it is in fact marvelously identifiable, robust, and self-contained.
As for disk space in terms of bits: that is by now irrelevant. Every development system can probably store hundreds or even thousands of copies without filling up. Add to that the replication to other servers and destination machines, and the issue is really moot.
-jcw
AvL "As for disk space ..." ... we would not need to compress the contents of a starpack. Having to uncompress some code for each execution may be faster for a small number of executions, but quite bad, if more users on a system would use this application at the same time - the OS cannot share the uncompressed chunks in memory between processes (not to speak of different users). Starpacks seem to be a good idea for applications that run on single-user machines (generally the windows-world), but less so on servers (exceptions ascertain the rule:-) Starpacks seem to go the route that java has gone: all runtime-stuff is compressed on disk and unsharable in memory.
It's a good point, but a complex one. The executable can be shared (unless upx-compressed). Uncompressed storage in the starkit/starpack is possible by wrapping with the "-nocomp" flag. The main remaining issue is that Tcl reads and copies scripts into memory anyway - it would need to use memory-mapped file techniques to really stop doing this. I'm experimenting with such designs, but doing the same in the Tcl core would require a major change to Tcl_Obj. -jcw
LV On the other hand, as car manufacturers find some levels of defects, they fix the assembly lines so that the new cars built no longer have those problems. So while J Smith car owner does not go out and buy a new car, what s/he DOES do, at least here in the States, is receive a notice that some defect has been found and that, either for free or a reasonable cost, the vehicle can be returned to a dealer to have the defect fixed. And new buyers find the defects fixed.
That's not a counter-example, but another analogy. -jcw
HJG 2008-11-24 The link to [1] https://www.tcl-lang.org/starkits/tkcon.kit is dead, same for [2].
stevel - links to mini.net/sdarchive are progressively (and slowly) being changed to the new location - https://www.tcl-lang.org/starkits - please amend any you see.