Jason Tackaberry wrote: > Doing realpath() would result in this unexpected behaviour, so > better to handle symlinks smartly.
Agreed.
>> 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.
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.
> # 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.
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.
>> 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.
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.
> 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.
> 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.
That is one solution. Not a good one, but it will work.
> 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.
I have to think about that. I have specific needs for Freevo in one or
two places and I need to check the possibilities.
> 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.
No, nothing should use the db without using kaa.vfs.
>> 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.
Agreed. kaa does not know about fxd files, so I need to find a
solution for Freevo. But kaa.metadata needs to output some information
about what files were or could be used.
> 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.
But when you delete the fxd, it has to be reverted. Again, I need to
do some more thinking here.
>> 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.
OK, if you add a comment in Freevo, it would be in the database. But
you can also add comments with the xml file. That's all I was saying.
>> BTW, it would be cool to get all files in a dir including subdirs.
>
> Do you mean recursively list an entire tree?
Yes.
Dischi
--
We live in a society where pizza gets to your house before the police.
pgp6qgqXbuDVg.pgp
Description: PGP signature
