Leo Comerford wrote on Wed, 18 May 2005 12:50:38 +0100: > But if you have relation-directories and the ability to find the > pathnames of a given file, you can do everything you can do with > subfiles, just as nicely, and more besides. And if subfiles are > completely redundant and bad news anyway, we shouldn't have them.
I prefer subfiles (or fildirutes) as being easier to understand. But maybe that's just due to lots of experience with using file hierarchies. I can see having a relational system, but I'd always want to also have a directory hierarchy namespace, so that all files can be named. Having those relationship directories seems kind of clunky - since they're not located near the object being investigated. Though that's a GUI matter of making the system file browser pop up a "Show Relationships..." menu item as contrasted with drilling down to a subfile directory listing by clicking on an item. > The idea is that if you want to assert a single-place predicate of a > file, like "file x is important", you just use give the file an > approprate full path"name" ('~/important' or whatever). If you want to > assert a multi-place predicate - a relation - like "file x is more > important than file y" then you use a relation-directory. That goes > for every kind of multi-way relation/association you might want to > assert between files - one to one, one to many, many to many. Good point about sorted relationships. Reminds me a bit about attributes in BeOS and using them to sort file listings. There may be a duality between relation directories and a file system with indexed attributes, like BeOS's BFS or a true file-is-a-directory system. One system has a relations directory stuffed with property values of a similar kind (such as short text descriptions for photos). The directory implies the contents type (short text description), while the items also link to the thing they are expressing a relationship about (the photos). The other system treats the object (the photo file) both as readable data and as a directory with attribute-ish sub-things, like a sub-file containing the text description of the photo. File types are done as meta-data (a couple of bytes attached to the object nodes), marking the photo as JPEG data and the description subfile as text. For bonus points, the file type can also appear as a virtual child object to make accessing the file type the same as accessing other data (no new APIs needed). Another advantage is that doing a directory listing of an object gives you all its relations too (multiple parent objects listed). Ordered Relations? Now how to do an ordered relation? For example, say you have the shooting date for each photo as a property and you want to find all photos shot on a given day, or range of days. Either system can be used to find them. With relations, look in the relation directory that stores shooting dates and sort by name (assuming that the naming of the items reflects the date). Say, just how do you name the relation items? You had aardvark and other animal names in your examples. Should the actual value be used (like the whole photo description text) as a name? Or is the directory magically sorted by property value somehow? Or is the relation directory just a concept, not actually browsable? In the file/directory/attribute system, one of the file types would be "shooting date" and all files with that type would be automatically indexed, if you had created an index for "shooting date" earlier. The index merely stores the relevant value (a date) and a link (inode number?) to the file. To find the actual photo with a given date you'd have to find the parent of the attribute-ish subfile thing the index gives you. Come to think of it, if you display the index as a directory, you kind of have your relation directory. I had that as a feature in AGMSRAMFileSystem, using the attribute values as the name of a symbolic link pointing to the related item. But it didn't occur to me that it was like your relation directories until now. Here's an example - the last modified index for all files. The date is in microseconds for better sorting, and lack of time zone printing functions in the BeOS kernel: Fri May 27 20:12:36 24 /RAMDisk/.Indices>ls -l last_modified total 1497 lrwxrwxrwx 0 agmsmith agmsmith 2 Sep 10 2001 1000158923000000 #604f52f8 -> /RAMDisk/PineappleData/news/Servers/NLZ/music.in_fidelity lrwxrwxrwx 0 agmsmith agmsmith 2 Sep 10 2001 1000159028000000 #6094a790 -> /RAMDisk/PineappleData/saved/Keepsakes/PM999697.pmf lrwxrwxrwx 0 agmsmith agmsmith 2 Sep 10 2001 1000172295000000 #608fb640 -> /RAMDisk/PineappleData/saved/Keepsakes/PM999685.pmf lrwxrwxrwx 0 agmsmith agmsmith 2 Sep 18 2001 1000849618000000 #60bd8278 -> /RAMDisk/mozilla/res/samples/toolbarTest1.xul lrwxrwxrwx 0 agmsmith agmsmith 2 Sep 18 2001 1000849618000000 #60edc108 -> /RAMDisk/mozilla/res/samples/scrollbarTest1.xul lrwxrwxrwx 0 agmsmith agmsmith 2 Sep 18 2001 1000849627000000 #608eb2e0 -> /RAMDisk/mozilla/res/samples/tab.xul ... However, that brings up the extra power of queries. In BeOS you can build a query string something like "ShootingDate=May 27 2005 & Location=*Home*" for all photos shot on May 27th at locations that contain the word "Home". It's a combination of relations. Internally the simple query processor just finds the files matching one of the indices (Shooting Date would be the better choice since it is more constrained) then checks the resulting set of files against the rest of the query. If it's a duality, I suspect you'd be able to do something similar with your relation directories. For that matter, I was planning to add a feature for showing query results as a virtual directory, so that queries would be available to ordinary file namespace programs, like "ls". Unfortunately the real world intervened and I had to end my sabbatical. Lots of nifty topics still waiting there for someone to research and implement! - Alex