Crazy Idea

When web servers were first built, there was a one-to-one mapping between virtual files (i.e. addressable via http) and the physical files (the ones in the file system). Over time, two important capabilities were added. First, the contents of a given file became dynamic. So while you the reader always come back to default.aspx (or rss.aspx as the case may be) the content changes everytime I post something new. Secondly, the physical file dependency was removed. It’s not used much in dasBlog, but in .TEXT this is very prevelant. My last post on blogs.msdn.com is located at http://blogs.msdn.com/devhawk/archive/2005/02/01/364380.aspx. Obviously, there is no actual file named 364380.aspx, .TEXT uses the filename as a key into the DB to find the actual entry content. This technique is used extensively in the new MSDN2 (if you haven’t already, check out Tim Ewald’s MSDN Magazine article about URL design for MSDN2).

So now for the funky idea part – why couldn’t we generate dynamic local files the same way? I’m not sure I’ve got a great use for this yet – most of the apps I use are programmable to some extent, so dynamic content can be generated at the app level rather than at the file system level. But I’m thinking there may be some scenarios where it would make sense to do this at the file system. For example, in the new Winter Fun Pack there’s a new version of the WMP blogging plugin that autoupdates the Outlook and Outlook Express signature files whenever the song being played changes (a la Duncan’s Coding4Fun article). But with virtual files in the file system, you could generate these files when they are accessed instead of writing new ones everytime the song changes, even if Outlook open.

Of course, our local file system typically has more writing activity than the web, so I’m thinking this isn’t that great an idea. But I figured I’d share in case someone else could think of some good uses. Or maybe this already exists and I just don’t know about it.

Comments:

Humm i think Linux (i'm sure other unixes have it too) has this, /proc/* for example. But this is done at a kernel level, not sure if such thing exists at the user process level, i bet there is something. But if there isn't i sure it would be an easy hack. What kind of semantics were you thinking? would these virtual files be seekable? how would they be versioned? what kind of concurrency controls would need to exist? Sure pull instead of push (with a lot of unnecessary pushing ocurring in your described scenario) is nice, but i wonder if the effort would be worth it? just wondering.
I agree that there are some exciting possibilities for this type of thing, and I use several "virtual filesystems" everyday (Daemontools (for mounting ISO files), web folders (for mounting WebDAV directories)), etc. If you zoom in a little closer, I think you'll see all filesystems are virtual. There aren't actually any files on a disk...just sectors/blocks. But I think there are some dangers too. I think the assumption that filesystems are fairly static and computationally cheap to access is too baked into most software. I think this goes back to the idea that, "boundaries should be explicit." If you really wanted to, however, you could make a fairly decent dynamic virtual file system using web folders and WebDAV pointing at a web server.
Check out the "subst" command that comes with Windows. This might get you part of the way there.