From e960c43cb79737b96de916368b5c558d5e6c75b4 Mon Sep 17 00:00:00 2001 From: Vince Darley Date: Tue, 4 Sep 2001 11:29:19 +0000 Subject: [PATCH] doc --- Readme.txt | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/Readme.txt b/Readme.txt index e1a069e..ebcf141 100644 --- a/Readme.txt +++ b/Readme.txt @@ -13,7 +13,9 @@ is to expose Tcl 8.4's new filesystem C API to the Tcl level. Since 8.4 is still in alpha, the APIs on which this extension depends may of course change (although this isn't too likely). If that happens, it will of course require changes to this extension, until the point at which 8.4 goes -final, when only backwards-compatible changes should occur. +final, when only backwards-compatible changes should occur. Currently it +requires a version of Tcl from September 5th 2001 or newer (if it compiles +without warning, you should be fine). Using this extension, the editor Alphatk can actually auto-mount, view and edit (but not save, since they're read-only) the contents of .zip files @@ -60,6 +62,23 @@ the archive itself. The result of this is that Tcl will then see the archive as a directory, rather than a file. Otherwise you might wish to create a dummy file/directory called 'local' before mounting. +C versus Tcl +------------ + +It may be worth writing a vfs for commonly used formats like 'zip' in C. +This would make it easier to create single-file executables because with +this extension we have a bootstrap problem: to mount the executable +(assuming it has a .zip archive appended to it) we need to have +'vfs::zip::Mount' and related procedures loaded, but this means that those +procedures would have to be stored in the executable outside the zip +archive, wasting space. + +Note: Richard Hipp has written 'zvfs' which uses the older, less-complete +vfs support in Tcl 8.3. It is GNU-licensed, which makes distributing binary +versions a little more complex. Also Prowrap contains a similar zip-vfs +implementation using the same old APIs (it is BSD-licensed). Either of +these can probably be modified to work with the new APIs quite easily. + Limitations ----------- @@ -78,8 +97,10 @@ Future thoughts See: -http://www.ximian.com/tech/gnome-vfs.php3 +http://developer.gnome.org/doc/API/gnome-vfs/ +http://www.appwatch.com/lists/gnome-announce/2001-May/000267.html http://www.lh.com/~oleg/ftp/HTTP-VFS.html +http://www.atnf.csiro.au/~rgooch/linux/vfs.txt for some ideas. It would be good to accumulate ideas on the limitations of the current VFS support so we can plan out what vfs 2.0 will look like (and -- 2.23.0