On Tue, 2005-08-23 at 16:30 +0200, Dirk Meyer wrote: > > unique id for the dvd.) The mount point for removable media isn't very > > interesting to the user. > > No? Don't only think of DVDs. You can have normal cds with a complex > dir structure. When I add my vacation data dvd in drive 1, it would > look like /mnt/drive1/sri-lanka/day1/foo.jpg and when I change the > drive, it is /mnt/drive2.
Yes, but what I mean by "not interesting to the user" is that the user doesn't care that it's mounted under /mnt/drive1 or /mnt/drive2. In fact, a sane UI wouldn't even show the user that at all. It would just show the user "DVD disc titled 'Foobar'" and its mount point is basically hidden. > OK, now you are saything something similar to me. All files and > subdirs are in a tree starting at the disc itself. OK, so the disc is > more or less a '/' node. Yes. One could have a more general "removable" object type for data media (i.e. not audio CDs or DVD movies) where the name field is a unique id that's particular to that media. That's actually kinda hard, since the filesystem label isn't guaranteed to be unique. Well, ext2/3 has a uuid that we could use, but that doesn't really solve a problem since most removable media will be FAT. Does FAT have uuid as well? At any rate, yes, the point is removable media will act as the root object, not the mount point dir in the filesystem. > I don't think that is a good idea. When kaa.vfs knows about all my > audio cds and a search for an artist, it would be stupid to remove > results in user space. I understand the inelegance of it. But solving this problem at the database level is trickier than just adding an extra clause to the query. The problem is that because objects can have arbitrary parents that exist in other tables (a row in the objects_image table could have a parent in objects_dir, and the next row in objects_image could have a parent in objects_dvd), you can't just do a join because you don't know what table to join. It's not even enough to create a separate table objects_global or something, that has fields (type_id, object_id, available) and do an outer join on that table and select rows where available != FALSE. This won't work because an image under a subdir of a DVD will have a parent that's in objects_dir, not objects_dvd. What we really want is to traverse up an object's ancestry and only match the row if all of its parents are available. Even if this was possible with SQL (and it might be), it would probably be slow and confusing to maintain. That's why I say we just select all the rows that match the user's query and then kaa.vfs will, in "user space", remove the rows which have a parent in its tree that's not available. > > Well, that's how we should implement it at first, and look at that > > later for an area of optimization. It's not a common use case > > however. > > Not? It happens for all audio cds. But I mean queries in general aren't going to be as common as listing all files in a directory. If kaa.vfs has seen 10 of your Enya CDs, you currently have one of those in the drive, and you do a query for artist="Enya", you'd expect it to only match the songs for the CD you currently have in the drive (and any of your Enya MP3s that are on hardisk, of course). So the point is if the database query returns 100 rows (say 10 songs in 10 disks), kaa.vfs will then figure out that it needs to remove 90 of those rows before returning to the caller. It'd be nice to solve this right in the database query. It just might not be worth it. And I think it's not the kind of thing we need to optimize right away. > But when you delete the fxd, it has to be reverted. Again, I need to > do some more thinking here. Assuming kaa.vfs has hooks for custom files (and it must), you register .fxd files with a handler, and if the fxd file gets deleted, the handler gets called, and you can then update the vfs to revert the changes that were made when the handler got called when the fxd was added. Jason.
signature.asc
Description: This is a digitally signed message part
