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
_______________________________________________
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
