Hi guys!
On Tuesday 23 August 2005 16:30, Dirk Meyer wrote:
> >> 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.
"Stupid" only if it's expensive and can be prevented, no?
My idea is that Freevo uses custom DB columns to cache which files are
supposed to be most certainly visible (harddisc) or must be checked
(removable media). Then the certain files can be displayed quickly, and the
others added as soon as possible.
> > 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.
My first thought were some kind of timestamps on each object, but that's
obviously a log-for-the-poor-man and could make problems with deletions or
similar. Just throwing it into the brainstorming pot.
> > 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.
That could also be supported with the beforementioned flags; e.g. Freevo could
mark the part[12].avi as most probably shadowed parts (similar to the
removable media objects), and..
> But when you delete the fxd, it has to be reverted. Again, I need to
> do some more thinking here.
..if this happens, they would appear a moment later.
Getting the number of objects in a directory would boil down to a simple
select with a condition on the flag, if you want a very fast answer.
You can still check the directory's mtime to see whether that first guess is
potentially wrong.
> > 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.
Actually I like the xml file approach, since that makes it possible to easily
handly the metadata together with the files from a user's perspective.
Imagine I added comments to my photos and do a backup of the photo dir, or
want to send everything to a friend (who's using Freevo or a future kaa-using
app, too), I would be disappointed if the comments simply disappeared.
IMHO that's very similar to the thumbnail stuff, with the difference that
metadata that cannot easily be regenerated is more precious to the user.
FWIW, I found it also sad that fd.o decided to put thumbnails into a seperate
VFS dir (which is pruned to a specific size); for e.g. photo collections I
liked it much more to have a permanent thumbnail storage.
--
Ciao, / / .o.
/--/ ..o
/ / ANS ooo
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Freevo-devel mailing list
Freevo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-devel
