On Wed, 2008-11-26 at 11:34 -0800, Darren Duncan wrote: > I agree with the idea of making Perl 6's filesystem/etc interface more > abstract, > as previously discussed, and also that users should be able to choose between > different levels of abstraction where that makes sense, either picking a more > portable interface versus a more platform-specific one.
Agreed on both counts. > Following up on Tim Bunce's comment about looking at prior art, I also > recommend > looking at the SQLite DBMS, specifically its virtual file system layer; this > one > is designed to give you deterministic behaviour and introspection over a wide > range of storage systems and attributes, both on PCs and on embedded devices, > or > hard disks versus flash or write once vs write many etc, where a lot of > otherwise-assumptions are spelled out. One relevant url is > http://sqlite.org/c3ref/vfs.html and for the moment I forget where other good > urls are. There are also higher-level VFS systems, such as Icculus.org PhysicsFS, which goes farther than just abstracting the OS operations. It also abstracts away the differences between archives and "real" directories, unions multiple directory trees on top of each other, and transparently redirects writes to a different "trunk" than reads: http://icculus.org/physfs/ I want to be able to support that functionality in a way that still allows me to open and close PhysicsFS "files" and "directories" the way I would normally. I want to be able to layer it *under* the standard Perl IO ops, rather than above them. The following is all obvious, but just to keep it in people's minds and frame the discussion: Being able to layer IO abstractions is at least as important as the basic OS abstraction itself -- as well as the ability to use the high level abstraction most of the time, but reach down the stack when needed. This implies making best effort to minimize the ways in which upper layers will be hopelessly confused by low-level operations, and documenting the heck out of the problem areas. These layers should be mix-and-match as much as possible, with abstractions designed with common interfaces. Certainly Perl 5's IO layers, as well as any networking or library stack, are prior art here. > To summarize, what we really want is something more generic than > case-sensitivity, which is text normalization and text folding in general, as > well as distinctly dealing with distinctness for representation versus > distinctness for mutual exclusivity. Yes, definitely. > [This] implies that > sensitivity is special whereas sensitivity should be considered normal, and > rather insensitivity should be considered special. If only that were true in other areas of life. :-) -'f
