Hi again!
Am Mittwoch, 01. Oktober 2008 19:56:25 schrieb Jason Tackaberry:
> The database arranges objects in a parent/child relationship,
> corresponding to the filesystem hierarchy. All objects have a media
> object as their top-most ancestor.
That's IMHO a logical, obvious structure and exactly the same one that I used
in my home-grown filesystem indexing code.
> One of the design goals for kaa.db was to allow plugins to extend the
> database at runtime by adding custom attributes. This is generally
> transparent to other plugins using the same database (except with
> respect to potential name collisions).
Thanks for summing that up, that's how I remembered it from your discussions
but I never looked at the code (except recently, but that was unfortunately
an older non-working SVN state and I was offline).
> beacon, which builds on kaa.db, exposes much[*] of this flexibility.
> Your requirements in 2) can be satisfied by extending the media object
> by allowing a user-editable label and disk number. This can be
> accomplished by calling (on the client side):
>
> # This can safely be called more than once.
> kaa.beacon.register_file_type_attrs('media',
> user_label = (unicode, ATTR_SEARCHABLE | ATTR_IGNORE_CASE |
> ATTR_INVERTED_INDEX, 'keywords') user_id = (int, ATTR_SIMPLE)
> )
Thanks for the pointers/code, the name "user_label" is exactly what I had in
mind; maybe this could be "the" standard attribute for this purpose (as I
wrote, I'd use the disc's iso9660-label as fallback if this attribute has not
been manually set).
> The above creates two new attributes for the media object. user_label
> is a unicode and can be searched on directly (because it is a column in
> the media objects table), and as well gets mapped to the 'keywords'
> inverted index, which means that any keyword searches which match words
> in the user_label would include the media object.
That's really clever. I did not expect such powerful features from the above
LOC. :-)
> > Also, my impression of kaa.beacon is that it's a indexing and caching
> > system.
>
> I suppose that's a pretty simple description of it. It also takes care
> of thumbnail generation.
Yes, but what I had in mind was the characterization of beacon as some
component that only generates data that can be deleted and re-generated at
any time. AFAICS it makes sense to seperate such data from more expensive
one (user-generated or user-selected web content), even though both would fit
very well within the same DB structure.
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.
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.)
That's what I had in mind when I wrote:
> > While it should be feasible to write export/import functionality to
> > backup its index (or maybe even import 3rd party indexes as wished by
> > Sylvain in the above thread), I thought about making user-generated data
> > more visible and permanent by writing it to .fxd files. Would that make
> > sense?
> [...]
> I don't know if freevo 2 does away with fxds. Dischi? I suppose fxds
> could still be used as an overlay on top of beacon. But they may
> overlap too much in function to make that ideal.
Maybe the overlap vanishes when kaa.beacon is declared to only cache and index
data (IMHO thumbnails are very similar to a cache or index) and in fact both
would complement each other quite well?!
Thanks for your answers,
Hans
-------------------------------------------------------------------------
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
