Common spec/interface for file metadata

Nicolai Haehnle prefect_ at gmx.net
Mon Sep 5 21:03:52 EEST 2005


On Monday 05 September 2005 17:30, Benedikt Meurer wrote:
> > The problem is then how do you take advantage of existing frameworks
> > under developemnt like Beagle, Kat and Tenor. They are the ones that are
> > producing the metadata in the first place and they each store it in
> > their own databases (Beagle uses lucene's DB, Kat Sqlite3, Tenor
> > Postgres and my own implementation of a metadata framework will use the
> > embedded mysql lib) so its kind of difficult to standardise it
> > in-process plus you also have a potentially huge dependency list which
> > no platform would accept in its core. Unfortunately I cant see any other
> > way round this but IPC.
> 
> 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.

Forcing a common backend is unrealistic. After all, saying "SQLite" isn't 
enough, you'd have to standardize on the database layout as well, and that 
would force everybody to the lowest common denominator. Basically, you'd 
kill invention in that area.

Since your concern seems to be performance, why not define a *plugin* 
interface for dynamically loaded shared objects instead of doing IPC? This 
allows you to avoid some overhead while still providing interoperability.

cu,
Nicolai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050905/4ad6f7ef/attachment.pgp 


More information about the xdg mailing list