I don't understand your point. Saying that vfs only has client support for webdav doesn't mean you're half way there. It means you haven't started yet when it comes to providing webdav support for AOLserver. The client support is of little use and means nothing when it comes to integrating webdav in aolserver. There are plenty of webdav clients around, so vfs contributes nothing new other than a way to access a webdav server from a tcl script. Sure, somebody could write a nsdav module, but I don't see anybody stepping forward to do it. Are you going to write it? Myself, I'm not so interested in developing nsdav. Sure, I'd like to see somebody do it, as I definitely think that it has a lot of potential. In general, the AOLserver development community lacks critical mass for bringing forward new technologies. I hate to say it, but Zope had webdav support before we started porting 3.2.x.
If we can leverage code from other opensource projects then, why not? The point isn't that a webdav server couldn't be developed in Tcl, I'm sure it could, but rather that tools like nsjava might provide an easy way to integrate webdav support into AOLserver.
I just don't understand your bias against nsjava. After all, it is an Tcl extension module. In the examples I've posted, I haven't posted a single line of java code. It's all been Tcl. The purpose of nsjava is provide an interface to existing java packages from Tcl. nsjava is a tribute to the extensibility of Tcl. If weren't for the tcl object type system introduced in Tcl 8.0, nsjava probably wouldn't be feasible. Using nsjava does nothing to undermine confidence in our technologies, as it is implemented using key parts of the technologies that we use in openacs. The fact that webdav support is implemented in java is of little consequence, as the interface to it will be in Tcl, and as a developer using it, you wouldn't have to get involved in modifying the java code that implements the webdav server.
