- compression: because it's smaller (zipped)
- uniformity: because then, everything is a starkit
- evolution: because it's a good start if more gets added later
- packages: because you can also add all packages it needs, if any
- sdarchive: because it can then be submitted to the Starkit Developer Archive [1]
- stability: because the code is not editable as is (that's both a pro and a con)
- starpacks: because it's easy to turn it into a starpack, i.e. include the Tcl/Tk itself with it
A digression: wrapping vs. updatesThe "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. -jcwHJG 2008-11-24 The link to [1] http://www.tcl.tk/starkits/tkcon.kit
is dead, same for [2].stevel - links to mini.net/sdarchive are progressively (and slowly) being changed to the new location - http://www.tcl.tk/starkits - please amend any you see.