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
