On Mon, 2005-08-22 at 21:28 +0200, Dirk Meyer wrote: > That is something I also had in mind. But for a dir, you add the whole > filename and for normal files only the basename. Yes, you need the > whole filename to find a dir, but it is kind of ugly, don't you think?
Yes, but I mentioned this in my previous email. The VFS level would add separate objects for each path element and not store the base name. > And a dir id doesn't have to be unique. You should think of > softlinks. When I have to softlinks pointing to the same dir, the have > a different name (based on the softlink) but they have the same > content. Suggest then adding an attribute to dir type "link_id" which points to another object in the directory the symlink points to. Alternatively, call os.path.realpath on all paths so that symlinks are always resolved. In either case, this is handled at the vfs level, and not something the Database class concerns itself with. > I also would like to add a 'root' filed in the db. This should point > to the '/' dir for this file. If you have a disc, it has it's own root > dir to find files in queries you actually have right now (and to move > a disc between mount points). There can be arbitrary roots. A root is just an object with no parent. The root directory (/) would be the row in objects_dir table with parent_id=NULL. (There should only be one row in objects_dir with parent_id=NULL and that's /. This should be enforced at the VFS level.) > But how to find a file? To get information about > /home/freevo/mp3/Artists/Name_of_artist/Name_of_Album/Name_of_file you > would do too many selects just to get this information. Yes. Essentially to find a directory we would need to select for each component in the path. But there is an index on (parent_type, parent_id, name). These selects should be very fast. (With an empty cache, a select on a dirs table with 2500 directories takes 0.00065 seconds.) Furthermore, the VFS layer would provide a cache for these ids so they only need to be done once. > Next question (and this isn't easy at all): how do I now the > information in the db is still valid. Yes, we could use the mtime to > check that. This is part of the reason I want one process to handle the vfs and talk to it via IPC. Because if another process goes and writes to the database, suddenly anything that another process has cached is dirty. So it must always check the mtime on the database file before doing a query. > But e.g. images use bins xml files to get the data. When > foo.jpg.xml changes, foo.jpg needs to be parsed again. Only > kaa.metadata knows about such dependencies. I don't see why this is any different from foo.jpg itself changing. When foo.jpg has an mtime that's different from what the vfs knows about, the vfs must refresh foo.jpg (check its exif tags, say, regenerate thumbnail, etc.) If there's also a foo.jpg.xml that contains info about foo.jpg, the VFS would need to know about this as well. (I didn't know kaa.metadata used this type of file. What's it for? Why is it needed? Doesn't kaa.vfs deprecate all that?) > And how does Freevo know? Let's say we have more than just Freevo > using the same db. When this app is running and the file is updated, > how does Freevo know later that the information isn't ok for Freevo? See above. IPC. :) > To make it more complicated: Freevo wants to give the number of items > in a directory. But a fxd file can hide some video files (and even > contain more than one item itself). So Freevo has to know that his > information about the dir is invalid when the fxd fie changes. I don't see this as a vfs problem. It should be solved within Freevo. > Or should kaa.vfs know about this? We could add the fxd parsing to > kaa.metadata. I'm not big on fxds from a technical perspective. For MeBox, I never had any intention to use that kind of thing. Everything would be stored inside the vfs. I would just provide tools to edit vfs attributes directly at the command line. What kaa.vfs _should_ support is the ability for an application to associate a file with another file. So you could tell the vfs, "associate foo.avi.fxd with foo.avi" and then plug a handler into the VFS to support .fxd files. Then the VFS would monitor foo.avi and foo.avi.fxd, and if either of them changes, it would reprocess foo.avi (because .avi files should be handled directly by the vfs), and hen call the handler for .fxd files which would be registered by Freevo. This design would also be used for the .xml file you described earlier. > And what about playlists? Should kaa.metadata parse a playlist > file. It is not really a metadata, it is the data. And how do we store > a playlist in the db. It would be nice to do one select to get all > files for a playlist. Not everything the VFS does has to be kept in the db. The db is, by and large, a cache. A single place we put all the data about a file that we've accumulated from other places. Of course, not everything in the vfsdb is considered cached data. For example, an EXIF tag is, but a user comment isn't. (Assuming the user comment isn't stored elsewhere.) But for something like a playlist, the VFS can support opening playlists, but is there any reason that the vfs would need to keep that in the database? Jason.
signature.asc
Description: This is a digitally signed message part
