SEH As a self-teaching exercise, I wrote a sample virtual filesystem that utilizes as much of the Tclvfs API as possible, although its function is trivially simple. The virtual filesystems included with the Tclvfs distribution are instructive, but they take a lot of shortcuts.Because it simply mirrors a real filesystem location, I believe this vfs is maximally featureful.My aim for this vfs is to use it as a template for rapid development of new and more complex filesystems.The Mount, Unmount and handler procedures are completely generic and should never need customization for new filesystems. Thus the task of creating a new virtual filesystem is reduced to filling in the procedures for handling the eight subcommands of the Tclvfs API, as well as mounting and unmounting specifics.
SEH -- 10/14/04 -- I tidied things up a bit, and added an execution trace to the 'close' command so that it will throw a proper error if an error occurs in the close callback procedure. Not too relevant for this vfs, but for more complex ones built on the template.I also added a "-volume" option to the Mount command, so you can now do things like:
::vfs::template::Mount -volume $env(HOME) C:/on Unix, and make pathnames originating on Windows acceptable. Problems syncing cross-platform filesystems solved! Schweet!12/07/04 -- I had to rewrite the Access procedure to correct a misunderstanding about how the access handler worked; I took the opportunity to optimize it to minimize the number of disk reads required.12/22/04 -- I made it more of a real template by removing references to "::vfs::template" within procedure bodies and replaced them with [namespace current]. Now the Mount, Unmount and handler procedures can be copied and pasted directly into new vfs code without editing.
20040720 CMcC: I just saw a real use for this - a trace fs. Someone was trying to work out why copy -force was failing, it would have been nice to be able to say to them: mount this on your directory and look at the log. Trivial addition to this template - log each argument to, and result from, underlying file system.snitvfs has a reimplementation of this, in Snit.
LV Would it be beneficial a) to include this template with tclvfs and b) to upgrade the existing tclvfs examples with the features your template provide?SEH I would love to have my work incorporated into the tcllib, but I don't think it's my decision.CMcC With all respect to SEH, whose idea the template vfs is, I would like to suggest that the template vfs either be rewritten in Snit, or a parallel version in Snit written and maintained as part of the same package. I have rewritten Steve's template vfs in Snit, for the reasons I give below (although I'm not suggesting that my version is necessarily the best possible version.)The reasons to use Snit for template vfs:
- Very often in tclvfs code one is forced to carry state around with each mount-point. There's no easy/neat way to do this in pure templates (as code inspection will reveal :)
- Consistent -option handling, with defaults.
- Clearer interface definition and composition - Snit is designed to plug components together.
- OO paradigms are interconvertable more easily than rewriting something into OO. Now's a good time to make the choice to go OO - before it's too late.
- Easier to extend a Snit type to extend functionality than to do the same with pure-namespace implementations.
- (add here)
- I don't know/use Snit ... <contra>either it's worth using or not, lack of training isn't an excuse.</contra>.
- I don't like Snit ... <contra>suggest another system, suggest some improvements - argue about it.</contra>
- I don't like OO / I've got my own OO style ... <contra>two words: code reuse</contra>
- Snit's slower than pure template code aka Snit is no speed demon... This is the hardest one to answer for tclvfs file systems which are speed critical - but what are you doing using tclvfs for a speed-critical facility? Snit's getting a lot of optimisation attention, and this will only improve the performance over time.
- a consistent interface to tclvfs where there are some incongruities (smoothing out the rough spots.)
- genuine extensions of tclvfs functionality which could be better implemented in tcl than in C.
LV Have the tclvfs issues mentioned by SEH been communicated to the tclvfs project via the bug report and feature request queues?SEH -- They're all in there.
Let's take 'em one at a time: Can't read from channel in close callback I have written this tip  which I believe will fix the problem. CMcC