The VFS appears mounted in a specific point on the actual filesystem. There's no problem accessing files outside or inside the VFS. I have a starkit, for example that implements a launcher for X11 clients to windows X11 servers. That starkit is able to, and perfectly well does, store session configurations in a file in the 'normal windows locations $AppData\xlauncer'. The application can find the top-level of the starkit vfs via the variable starkit::topdir See e.g. http://wiki.tcl.tk/4080 for more information and sample code. Ron. 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 <fox / nscl.msu.edu> 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 <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/ >>> >> >