I’m rewriting niven’s FileSystem. The FileSystem originally supported different backends transparently to the user (local filesystem, web based files, etc.), but I’m removing all this stuff in favour of a more streamlined, easy to use file system which supports local files only. I’m not entirely sure whether I should keep a backdoor for archive or web-based file systems in it, as they don’t map very well to a general file system - archives and the web are read-only filesystems, and it’s probably better to put them into a seperate class, in order to make it clear to the user that he can’t use them as general-purpose file systems. Some ideas that float around my mind are special calls in the file system that allow the user to request a file using an URL, which would in turn invoke the appropriate file system.
The problem with a file system supporting archives and normal files is: If you load a file, it might happen the file is loaded from an archive, but if you modify it, the modifications happen to a local copy of the file as you can’t work inside the archive. Now image the archive loader has a higher priority than the local loader, and you’ve got your dillema. You can’t really figure out what went wrong cause you have to wait until all backends finish and then it’s usually to late to find an error, and I don’t like this behaviour. I think I’ll enable different backends only for the
openFile call, as this is the only safe one - all other calls, like
createFile etc. will probably go into the local file system. This needs some thought, gonna write a bit more about it tomorrow. I hope to finish the rewrite and and the package export/import during the next week.