Discussion arising from A template virtual filesystem
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:
Rubbish reasons not to use Snit for vfs:
Real reasons not to use Snit for tclvfs:
Finally, the best reason for using Snit for tclvfs: Much of the need for this Template vfs is that the tclvfs raw interface has some anomalies and some lacks.
The template vfs is really a shim to provide:
Some of the provisions in point 1 can eventually be moved into the tclvfs C core. Doing this over an OO interface is (I believe) easier and less disruptive than doing it over a pure namespace implementation.
Therefore: I would like to argue, passionately, for at least *some* OO interface, and preferably Snit (because it seems to be the ostensive standard for pure tcl OO,) whether or not this is maintained in parallel with or alternative to a pure namespace template tclvfs shim. I would also like to see the existing tclvfs' migrated to whatever system is adopted, and new tclvfs' adhering to whatever that system is.
Addendum: Of course, if it's a choice between a raw namespace template vfs and a no template vfs at all, I would emphatically prefer the namespace template vfs.
SEH - 10/18/04 - My motivation for writing the template vfs was both to teach myself the Tclvfs API, and to verify that the Tclvfs package was in good enough shape to write software tools around, since I have been bitterly disappointed in the past by the gulf between claims of maturity in software and emergent reality. I'm very enthusiastic about the vfs concept, and I think it's a solution looking for problems. But the bottom line is the Tclvfs package is still officially in a beta state, and writing the template vfs did indeed reveal significant issues, some of which it appears will require changes in the core to address. Given that, I find it hard to justify the extra time and effort necessary to increase the sophistication of the vfs's as you suggest. No amount of polish in the vfs code will compensate for the inherent flaws in the underlying package. If the maintainers of the package are willing to commit to bringing it out of beta and fixing the identified issues, I will revisit the possibility of taking the vfs's to the next level. Until then, I'm going to put my available time into solving the problems I face in the present that the Tclvfs package and the vfs's are capable of helping with in their current state.
On the other hand, I was also hoping to spark interest in the Tclvfs package, which seemed to be languishing, so I am heartened by your involvement and advocacy. I hope the friction and noise will help to motivate the maintainers.
P.S. By way of further motivation, I think there are enough bits floating around now to envision, if consolidated, a sophisticated content management/version control/code distribution and installation service that would knock Bitkeeper on its heels and blow the doors off anything offered by any competing scripting technology.
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:
[1004273] Can't read from channel in close callback [L1 ]
The problem is that the user has requested a read/only or write/only channel, but the tclvfs' close process absolutely requires fuller access to the channel. For example: a user's write-only chan has to be read by close in order to be processed. Another example: a user's read-only channel has to be initially seeded by a memchan.
This can be modelled by the creator of a channel creating it with full permissions, and casting them away before handing them to a user, then re-aquiring full channel permissions at the point where the channel needs to be closed - that is, immediately before the tclvfs' close callback is invoked.
TIP 220 was originally written to allow C code to modify permissions, but this makes the permissions system mean nothing, as a channel's permissions could then be freely modified in an ad hoc manner.
TIP 220 has been changed to specify a weaker modification that is still powerful enough to implemenent the desired channel semantics: immediately prior to a vfs' close callback, a channel's permissions are set to the full set available.
Since the opening entity can in any case have complete access to any file it can create, and cannot successfully modify any file it couldn't have obtained from the o/s, and because the privileges are only available to the opener, and then at a point immediately before the tcl core is about to complete channel closing, re-escalation of privileges doesn't expose open channels to any additional risk of interference.