[Wasabi] Kicking of the Metadata spec - brainstorm

[Joe Shaw]

Hi,

jamie wrote:
> (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?)

Sorry, I must not have been clear in my previous email.  The entire 
point is to have fallbacks, because it gives you the richest experience. 
  You try (1) [inline metdata] and if it fails or doesn't make sense, 
you try (2) [extended attributes].  Only then if it fails do you do (3).

XMP sidecars are a possibility (probably as step 2.5), but they have the 
same problem as a centralized database: they don't follow the file 
around.  If you copy a file, rename a file, or send it as an email 
attachment, if you don't know to do the same with the sidecar you'll 
lose it.  gnome-vfs/gvfs/kio support for this helps the issue, but it's 
not as tightly coupled as xattrs.

And you say that (1) and (2) fail in practice, but this just isn't true. 
  F-Spot stores its tags as XMP data in image files quite successfully. 
  Rhythmbox, sound-juicer, and Banshee have been putting id3 tags in 
MP3s forever.  As for xattrs, we've been using them very successfully in 
Beagle for over 3 years (with a transparent fallback to an sqlite 
database when it's not possible).  So all of this is possible to do and 
give the user a good experience.

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

Notifications are tricky, but I think it might be possible to do them 
within a library using inotify (or FAM or other appropriate method). 
gconf is a daemon because (a) mechanisms like these didn't exist and (b) 
because absolutely everything touches it, and it doesn't make sense to 
continually reparse its XML files.

With approaches (1) and (2), notification is trivial.  You get 
WRITE_CLOSE event and ATTR_CHANGED events on the files themselves.  For 
(3), you can watch the database file for changes.  (This means you have 
to timestamp rows, but once that's done you can trivially SELECT for 
changes newer than a certain time.  This is a good thing to do in any case.)

Joe