Common spec/interface for file metadata

Benedikt Meurer benny at xfce.org
Mon Sep 5 19:46:13 EEST 2005


Jamie McCracken wrote:
>> IMHO, the proper way to address this issue is to standardize the
>> metadata backend instead of the interface. If everybody would use SQLite
>> (for example), then it would be easy to access the metadata from every
>> application without the need to do any IPC. And it wouldn't matter if
>> the metadata index was generated by Beagle, Kat, or whatever other
>> systems might exist today. You would have one single metadata storage,
>> and every application that wants to access the metadata can simply link
>> to SQLite and read from the database (it might be a good idea to provide
>> a simple wrapper library with get_meta_data(), etc.). I don't care if
>> it's SQLite, Berkley DB or whatever, but it's IMHO important to have ONE
>> easy to use and fast metadata backend, not one backend per vendor.
> 
> I agree with you but I doubt we can persuade the established players
> (especially Beagle which uses a ready built lucene backend - they would
> find it tough to replace that).

I'm aware of this fact. Sad but true. On the other hand, Beagle is far
from stable (for example, the German "Linux Magazin" had a comparison of
various desktop search engines and Beagle didn't look good there), so
there's still room for improvement, and maybe while thinking about that,
they could switch to a common metadata backend.

And even if the Beagle guys aren't going to adopt the standard backend,
there are still a lot of other systems that would adopt it. For example,
I read that KDE 4 should offer better integration of Kat, and for Xfce's
new file manager, I'd also like to add search functionality based on
metadata (and display metadata in the icon/detail view where applicable).

> In absence of agreement from them, the
> common interface or common API is the only other way but bearing in mind
> Beagle is managed code, you cannot call any functions in it in-process
> from unmanaged code ergo we are back to IPC. Nautilus also forbids
> synchronous access to files so it needs to be async access only so again
> it would not be possible to use database in-process here too unless they
> have async api (AFAIK neither sqlite/BDB do)

Nautilus accesses configuration and metadata files synchronously, as do
most other file managers. And even if this should ever turn into a
problem, the file managers could simply do the metadata lookup in a
separate thread w/o any RPC overhead.

Benedikt



More information about the xdg mailing list