On Thu, 2008-10-02 at 11:50 +0200, Hans Meine wrote: > My idea was to use something like the .fxd files to make the latter types of > data more permanent (and Dischi thought along the same lines IIUC), which > does not prevent kaa.beacon from duplicating their content in a better > accessible way, i.e. through additional attributes in the DB.
Ultimately the question comes down to: where should authoritative user-created metadata be stored? The two obvious responses are 1. keep user-generated metadata in an fxd file, and have beacon parse it and duplicate it in its database (updating the db when the fxd changes), or 2. store the user-generated metadata directly in beacon's db and treat it as authoritative. It would be a useful exercise to enumerate the pros and cons of each approach. I don't know that I ever liked fxd files being sprinkled all over my media directory tree -- there is also the problem of fxds for read-only media (but is solved by the overlay directory). But sprinkling fxds may be better than the problems option 2 creates. > Probably, cover images should not really be duplicated but referenced by > appropriate filenames in the DB; for removable media, one would need a cover > image cache directory though. (That could be Freevo stuff at first, at least > I would not expect that functionality to bee within kaa.beacon.) Cover images for readonly media would be stored in the overlay directory, which beacon does support directly. Jason. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
