[Wasabi] Kicking of the Metadata spec - brainstorm

[jamie]

On Tue, 2007-02-20 at 23:31 +0100, Mikkel Kamstrup Erlandsen wrote:
> 2007/2/20, Joe Shaw <joeshaw at novell.com>:
>         
>         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.
> 
> Allow me to pick up on 3. :-) 
> 
> How would you manage locks on the db? Was synchronization issues not
> the reason why leaftag wasn't successful? I mean if you can't keep
> file tags synchronized then you are unlikely to succeed in keeping
> general metadata up to date... 
> 

Also there is notifications which you need a daemon for - its why gconf
is a daemon!

(as well as it being safer for concurrent access and writes too)


(3) is the safest and best way - you get a richer service that allows
all apps to share metadata and stay up to date.

(2) is great in theory but falls over in practice for loads of reasons
(mainly need for fallbacks). XMP sidecar is better and really just needs
GVFS and KIO slaves to support it transparently (IE to auto copy the
hidden sidecar file whenever you copy/move a file)

(1) fails  for same reasons (2) does - lack of compatibility means
having to have fallbacks in place for file types that dont have embedded
metadata. (if that fallback is going to be XMP sidecar then why bother
with anything else?)

jamie

>