On Tue, 2005-08-23 at 11:12 +0200, Dirk Meyer wrote: > Always resolve doesn't work. An example > > video/recordings > video/newstuff -> recordings
Calling os.path.realpath("/foo/bar/video/newstuff") would return
"/foo/bar/video/recordings" so this step could happen at the vfs before
checking the database. Nevertheless, I do think using link_id is
better, simply because if /home/tack/mp3 is a symlink to /data/mp3, and
I enter /home/tack/mp3 and then go up a directory, I would expect to be
in /home/tack, not /data. Doing realpath() would result in this
unexpected behaviour, so better to handle symlinks smartly.
> 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.
For DVDs, we could register a "dvd" type, where the name field is a
unique id for that DVD. (Whatever Freevo uses already to generate a
unique id for the dvd.) The mount point for removable media isn't very
interesting to the user. So kaa.vfs will need to know quite explicitly
about all kinds of removable media and handle that in ways that makes
sense for that media. This will need definitely need some
brainstorming.
For a) and b), these are unique to removable media. One could argue a)
describes what happens when you move a file, but for moving X to Y, the
vfs could treat it as deleting X and adding Y (unless it's using inotify
and X and Y are monitored directories, then it will know that it's been
moved and doesn't need to reprocess the file).
So the database will keep track of removable media in a way that makes
sense for that media. Register a dvd type and use the unique id for the
name field as I described above. Then we use that row as the parent for
files on the dvd. If the DVD has a bunch of images, then those files
added to the objects_image table will have a parent pointing to that row
in the objects_dvd.
# new DVD inserted ...
dvd_id = generate_unique_dvd_id(DVD_DEVICE)
db_dvd = db.add_object(("dvd", dvd_id), title="Whatever", ...)
for file in os.listdir(DVD_MOUNT_POINT):
db.add_object(("image", file), parent=("dvd", db_dvd["id"]))
So these images are parented with the DVD, not a path in the filesystem.
The mount point isn't used, only the dvd id, so if the DVD gets mounted
in a different place, the vfs doesn't really care.
> When I do a query for Artist=foo, I don't want to find results on disc
> not in a drive.
I'm not sure how to solve that within a database query. We would have
to return all rows that match the query and then filter out those
results that aren't currently 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.
> 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.
Well, perhaps the vfs shouldn't try to be everything to all things.
Maybe Freevo should have its own vfs database and nothing else should
use it. That way you can implement a layer over the vfs to implement
Freevo-specific things and Freevo processes can import that code to
access the vfs.
Alternatively, kaa.vfs could keep a log of changes that happened. An
app can connect to the vfs and then get informed of anything that
happened since the last time it connected, and it would have the
opportunity to then to update those changed files to reflect the
app-specific metadata.
This doesn't solve the problem of if a separate app writes directly to
the sqlite file and doesn't go through kaa.vfs. That's not a problem
worth solving, IMO.
> So kaa.vfs needs to know that foo.jpg depends on foo.jpg.xml and that
> changing the xml will change the jpg.
Right. Since kaa.metadata knows about those xml files, it makes sense
for this relationship to happen directly in kaa.vfs code. But for fxd
files, this is a Freevo thing, so kaa.vfs needs some mechanism to let an
app make its own associations and register handlers for these types of
files.
> See aboveL _later_. You can't communicate with Freevo when Freevo is
> not running.
But if you have freevo.vfs that's layered on top of kaa.vfs that
implements all the Freevo stuff, any Freevo app can import this and use
it and not have the problems you describe. But yes, if you want some
non-freevo app to be able to modify the vfs then the log idea I
mentioned above is one solution.
> >> 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?
Freevo wants to read a directory. So it queries the vfs for the
contents of that directory and gets a list. Then it reads the fxd file,
and sees "Ok, foo.part1.avi and foo.part2.avi should really be one file
foo.avi," so takes the rows returned from the vfs query and deletes
foo.part[12].avi and adds foo.avi.
Alternatively, the vfs can add a hooks at various steps, and the
application (Freevo) can register handlers. So freevo could register
with kaa.vfs a .fxd handler, and so the vfs queries a directory as
usual, but sees there are a few .fxd files there, and calls the
custom .fxd handler on each of those .fxd files before returning the
results of that query to the caller. Or something like that. :)
> 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.
If kaa.vfs offers a hook for Freevo to be able to tie .fxd files with
other files and add handlers for .fxd files, then this should be fine.
> 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.
Ok, well since vfs will be using kaa.metadata directly anyway, then it
can support this .xml file natively.
> Why not? The bins xml files contain title, comment, etc. So the
> information is stored elsewhere. But it is part of the image.
If a user adds a comment to an image, should a .xml file suddenly appear
in the directory? I wouldn't really want that. I'd expect the comment
to be in the database.
> BTW, it would be cool to get all files in a dir including subdirs.
Do you mean recursively list an entire tree? Or just get all directory
entries in a certain directory (whether those directories are files or
subdirs)? The latter can easily be done by querying parent=("dir",
dir_id).
Jason.
signature.asc
Description: This is a digitally signed message part
