Feel free to add whatever occurs to you by finishing the sentence 'VFS needs ...'
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
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.
A component of this is 'vfs::add, which gives the ability to compose file systems functionally. -- 20040612 CMcC
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 CMcC