Jason Tackaberry wrote: >> 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.
Always resolve doesn't work. An example video/recordings video/newstuff -> recordings Both point to the same dir, but they have different names. So I guess link_id is the best solution for this. >> 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 does a dvd has a parent? The parent of the disc depends where you mount it (which drive you use). And maybe the disc isn't even in the drive. We need support for a) Files that are not always at the same place in the tree b) Files that are not avaible sometimes. When I do a query for Artist=foo, I don't want to find results on disc not in a drive. >> 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. Yes, which caching it could be done. >> 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. How does IPC help? I run an app that uses the db. It checks for changes and writes it to the db. Now I want to use Freevo and _after_ running the previuosly app, I start Freevo. Freevo has no dirty information, but it doesn't know that some files in db have been rescanned and that the attributes Freevo stores in the db (and only Freevo knows about) are invalid. >> 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. So kaa.vfs needs to know that foo.jpg depends on foo.jpg.xml and that changing the xml will change the jpg. > (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?) The xml files are from bins (http://jsautret.free.fr/BINS/). Maybe other image tools adding metadata could be supported, too. >> 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. :) See aboveL _later_. You can't communicate with Freevo when Freevo is not running. >> 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. But how should Freevo know? >> 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. I don't like that. The good thing is that you can easyly move things around without caring about a db. People like to 'cp' and 'mv'. It's better for them to see a file they only need to move/copy, too. But maybe Freevo just reads the fxd file once and adds the data to the db. I'm not sure. The fxd files are very powerfull. You can define playlists, video items with more than one file and even urls for mp3 steaming. > 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. It doesn't work that way. First of all, Freevo desn't know about the foo.jpg-foo.jpg.xml dependency, only kaa.metadata knows that. And for fxd files, I'm not sure how to solve that with your idea above. >> 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.) Why not? The bins xml files contain title, comment, etc. So the information is stored elsewhere. But it is part of the image. And for playlists: it would be faster to use the db for that. BTW, it would be cool to get all files in a dir including subdirs. > 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? Only speed. Dischi -- while(!asleep) sheep++;
pgpcMB3Tm6Jf5.pgp
Description: PGP signature
