If the only access to information was through ioFTPD itself what features should iTCL provide? In particular, I see the new symlink resolving code is a nice addition, but if you had to do that without parsing the vfs files and instead called a new function what should it look like? I believe based on earlier research that ioFTPD never reverses a physical path back to a VFS path internally. So I'm assuming a script probably doesn't need to do so either, but if you do let me know and is it avoidable somehow?
Consider also that raided/merged directories will probably be much more common in the future when the disk spanning stuff gets introduced. Right now the resolve function can only return a single value and to not break everything immediately I'll probably end up adding a new resolver function with a different name that can return a list. Based upon my sidelined code for disk spanning it tried to keep all files in a single directory but subdirs could be on different disks. Thus xyz/cd1 and xyz/cd2 could be separated which means when looking at the directory and enumerating subdirs in the future it will likely be necessary to do that to all returned values from the new resolver function and merge the results.
The alternative is I've been looking at the TCL virtual filesystem interface which is much better in the new TCL releases. It looks possible that I could build an ioFTPD filesystem so that all normal TCL commands would operate on ioFTPD VFS paths and there would be no need to know the actual physical location of anything anymore! Paths would look like "ioFTPD:/VFS-PATH". How cool would that be? Would that be a good thing and if not why?
How about a sections iTCL extension for querying section information so you don't have to parse the .ini file? What info do you need? Propose an interface and I'll see what I can do
I've been adding features based on what I want in the server, but I'm happy to add features that directly support scripts especially if they remove dependencies on ioFTPD config files. This is also somewhat important since I've considered going to XML or something so that the config file is more robust. Of course that means I need to get scripts away from reading it...