From: Mark Roseman Date: 2007-12-21T21:34:58+09:00 Subject: Re: best way to distribute? Joe, the virtual file system hooks work comparably to 'real' file systems in that you can 'mount' a new file system at a particular point in the directory tree. Let's say you've downloaded your starkit to /home/foo/my.kit. When you run the starkit, the file system inside it essentially gets mounted at that location in the directory tree. So if you try to access /home/foo/my.kit/bar/data.txt, that will look inside the starkit. If you try to access /home/foo/other.dat, it will look in the regular file system, because the starkit isn't mounted there. So the nice thing is that it's all transparent. You just use the regular commands you'd used to operate on any old file, and the internal I/O system will figure out what 'filesystem' you're working on based upon the path names. Like any virtual file system based thing, the same approach is used for other filesystems... e.g. one that maps an http server to a file system. Mark Joe wrote: > How does this handle interacting with the filesystem outside the VFS? > So let's say you have files in the same directory as the starkit How > would you access them? Does it automatically assume you're accessing > something outside of the starkit unless you specifically say you want > something in the starkit? (IIRC that's how jars work in Java) > > Joe > > On Dec 20, 2007 4:39 PM, Ron Fox wrote: > > 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 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/ > > > > > > >