From: Ron Fox Date: 2007-12-21T21:34:59+09:00 Subject: Re: best way to distribute? I should once more say the intent is not to suggest that Tcl is better than Ruby... but that the idea of using virtual file systems to package software is a good one that gives you a lot of traction, and one that perhaps us ruby-ites could learn from, rather than struggling in the wilderness for a few years before it occurs to us. Looking at ruby2exe about the only thing it seems to be missing to get there is the idea that it's internal tarball is really a virtual filesystem, and could be accessed directly if ruby libraries had virtual file system support. The idea of virtual filesystems also provides much more than just starpack/starkit technologies. Ron. Ron Fox wrote: > 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 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/ >>>> >>> >>