tclVFS needs a filesystem which algorithmically transforms a path before using it, by applying a proc to it. This would be useful to provide per-user views of a file system, such as mounting ~/.tcl_lib/ over /usr/lib. -- CMcC 20040911
- It could be used in conjunction with A collate/broadcast virtual filesystem to stack personal directories over system-provided directories.
- It could possibly be used to provide per-project vfs views over other file systems, such as a versioning virtual filesystem, which is (IMHO) overburdened by trying to provide this functionality.
tclVFS needs a notifying fs such that whenever modifications are made to a monitored directory a callback is made. -- CMcC 20040905
tclVFS needs to support more of the core vfs functionality, specifically copy and rename. They are currently lacking, and so tcl's vfs core falls back to open/read/write/close for copy and copy/delete for rename, which are far slower than they might be.One difficulty with implementing this is that the tcl core implemented fallback only occurs if the VFS signals their lack with a NULL pointer. It would be cleaner if tcl core exported those fallback routines, and the tclvfs could determine whether the optional facilities were supported by a given tclvfs implementation, and fall back otherwise, or if the vfs interface allowed some form of error to indictate the need to fall back. Perhaps returning a break, or continue, or some other hack.Upon closer inspection, it appears that some kinds of failure from the vfs copyfile proc will be interpreted as a requirement to fall back, specifically if the tcl core can be made to think that the source and destination filesystems are different.
vfs composition: the ability to stack vfs on top of one another, ala [Plan 9]. It's got it, Cache VFS - complete with write-back.A component of this is 'vfs::add, which gives the ability to compose file systems functionally. -- 20040612 CMcCA more featureful facility is offered by SEH's A collate/broadcast virtual filesystem
versioning vfs: write to a file, and the diffs are store and accessed by globbing the file as if it were a directory. People have got to realise that the distinction between file and directory is a purely arbitrary and not particularly useful constraint.Implementation ideas: use CVS or metakit as a backing store? I'm tempted to use metakit with progressive diffs. I guess it ought really to be backend agnostic, but I'm not sure I want to go to the trouble. -- 20040612 CMcCSEH Try a versioning virtual filesystem.
