[Wasabi] Kicking of the Metadata spec - brainstorm

[Joe Shaw]

Hi,

On Tue, 2007-02-20 at 20:52 +0100, Jos van den Oever wrote:
> But reading, writing and searching metadata fields is something that 
> desktop applications will want to do more and more. Since there is, to 
> my knowledge, also no standard for reading and writing metadata in
> fd.o, this is a good opportunity to come up with it.

I agree.  But it is something that should be kept conceptually separate
from desktop search.

> Whereas we are talking about metadata that relates to files, they are
> working on a wider definition.

Do you mean files in their strictest sense, or also things like emails,
addressbook contacts, etc?

> When you think of writing metadata, you can e.g. think of the
> properties dialog in Konqueror where you can write title and artist
> for mp3 files. For searching you want to name this field and for the
> read/write api you want to name it too, so you might as well use the
> same language for that.

Indeed, and we should also use the same storage for it whenever
possible.  I envision a three-tiered system for actually setting
metadata on files:

1. Store the metadata in the file itself whenever possible.  Things like
id3 tags in MP3s or XMP metadata in jpegs.  This is ideal because it's
in a standardized format that most tools can read, and the metadata
follows the file around no matter where it's sent.

2. Store metadata in extended attributes on the file in the file system.
This has the benefit in that the metadata follows the data around within
a single system, and our desktop applications can be standardized around
a schema for xattrs.  Obviously this won't work for non-file items or on
file systems that don't support them.

3. Lastly, store metadata in some sort of centralized store, like a
sqlite database.  Keeping metadata in sync with data is harder, but
fortunately most of the data that would require this mechanism wouldn't
have mostly unique URIs.  I'm sure Jamie will disagree with me on this,
but I don't think this requires a constantly running daemon; a simply
library interface would probably suffice.

Joe