From: Ron Fox <fox@...>
Date: 2007-12-21T06:39:59+09:00
Subject: Re: best way to distribute?

  Some differentiations:
1.  starpack/starkit technology also supports a separation of the 
run-time (tclkit in Tcl/Tk land), and the application stuff (the stuff 
in the VFS).    This allows you to split the installer into a system 
dependent piece (the tclkit) and the application (starkit).  These can
be combined to a starpack which is system dependent.

2. Because the starkit part of the system is a full featured filesystem 
from the Tcl/Tk point of view it's possible to do a few neat things 
including automatic updating of the contents of the starkit.  The 
application, as it starts up can ask the world if there are newer 
versions and, if desired, confirmed by the user..all the application 
specific caveats you care to apply, can update itself in place.

3. Because the VFS that constitutes starkits is actually a metakit 
database, updates described above can be done as a transaction which 
either entirely succeed or entirely fail, but not leave the application 
in some funky state.

4. Again, because the VFS is a file system, the application can:
  - store data (e.g. ordinary help files) and access them as files.
  - keep e.g. configuration data allowing for a portable computing env.
    (e.g. a web-browser starpack could keep your book marks in its
     VFS so you could run around with your browser on a memory stick).

5. Because the starkit is a virtual file system to Tcl/Tk, there's no 
need to unpack the application into a temp directory for purely scripted 
apps.. or for apps whose extensions are built into the tclkit.  Only 
compiled loadable extensions need to be copied out into the host's 
filesystem so that they host system's dynamic loader can find them.  For 
large apps this can improve the startup time significantly.

Ron.


Adam Shelly wrote:
> On 12/20/07, Ron Fox <fox@nscl.msu.edu> wrote:
>>   Starpacks are executables that
>> consist of the intepreter, necessary compiled packages, and a virtual
>> file system appended to the back end of the executable that contains the
>> script, scripted packages and loadable binaries.
>>
>>   A similar sort of thing for Ruby might be a _good_ thing.  The
>> seminal paper on starpacks and the related starkit (the virtual
>> filesystem unbundled from the run-time) is at:
>>
> 
> Isn't this exactly what rubyscript2exe does?
> http://www.erikveen.dds.nl/rubyscript2exe/
>