dr.owned: Can you give me some examples of why knowing the command being run makes a difference as to what the script should return? It's possible to record the command being executed and pass that to the script whenever the virtual directory script is being executed and perhaps even when a pure virtual directory is being accessed from the cache. It would be difficult to entirely replace virtual directories with scripts because all commands would have to resolve their targets normally first (to support things like list -al /search/foo from /) and then handle things differently depending on it being virtual or not. That's a lot of commands to have to modify unless I found some cool way to do it I can't think of right now.
My initial implementation of virtual directories caches the last directory listing for each user per virtual mountpoint. I commented somewhere that once I could get some usage data that a single directory might be too small if people were using trees instead of say a simple /latest dir. I'm open to say caching 3-5 dirs per mountpoint. Let me know if you think that would dramatically change the number of times the script would be called in your implementations and if that would be desirable.
I also liked the ":" link prefix idea I mentioned before. That would allow you to symbolically link a directory but to hide the link in listings. That should dramatically reduce the script load I assume because the server would internally resolve things instead of having you return RESOLVED links from the script. If I can find/solve paja's problem I'll perhaps slip in this "new" feature into the next bugfix release sometime soon.
|