Am Dienstag, den 09.08.2005, 11:20 -0400 schrieb Joe Shaw: > (...) Thanks for your beagle/lucene insights. > If Nautilus started using EAs for this metadata, that'd be great. It'd > be faster and easier for us to read and index. Beagle isn't a general > metadata framework today; EAs seem to be much more appropriate for that > to me. But Beagle is there to index and search that data. Good. FYI, I'm working on a new metadata framework, which has providers and clients. - A provider can collect metadata for one or multiple MIME types. - A client can listen to metadata changes - You can call metadata_collect_for_uri_if_required and metadata_collect_for_uri_force The library will sniff the MIME type and as soon as that is ready, it will emit a "collect" signal for all providers that want to collect data for the detected MIME type or one of its parents. - After collecting the metadata, we set the "metadata-timestamp" xattr of the file. - Any metadata xattr value is supposed to be a string, which can then be used as tooltip etc.. I don't think it's worth adding images or other data types, considering that we already have a thumbnail spec and you typically want info like "Author", "Subject", "Width" etc.. - Providers will probably be added by modules, so that 3rd party developers can add their own - A provider is essentially a gobject which can propagate metadata changes through its properties. After a change (which always happens during a requested metadata collection) we a) call all metadata clients that were registered against the URI/MIME type/attribute in question (all of which are optional, so you can listen to all metadata changes as well) b) set the xattr "metadata-$provider-$property" to the value we retreive from our gobject. I'm not yet totally sure on the architecture and will probably encounter many pitfalls (wrt threads I'm a loser), but in the long term I think the library will stabilize and provide the foundation of future metadata fame. I'm very keen to get some feedback from experienced metadata hackers, especially whether they like the proposed architecture. -- Christian Neumair <chris gnome-de org>
Attachment:
signature.asc
Description: This is a digitally signed message part