[Wasabi] Kicking of the Metadata spec - brainstorm

[Joe Shaw]

Hi,

On Wed, 2007-02-21 at 14:26 +0000, jamie wrote:
> > 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).
> 
> for an app that wants to fetch metadata it seems to be a lot of hoops to
> jump through.
> 
> What would be fine is perhaps (1) + (3) and (2) + (3) so that an app can
> easily get the metadata regardless of where its stored (via (3))

You hide it all behind a single API; the consumer doesn't care where it
comes from, that's the library's job.

> I find it the other way round : xattrs fails as soon as you try and copy
> them off the volume. They simply dont work on the network, in
> attachments, to floppy/CD or USB stick etc. XMP sidecar seems to be the
> best choice here (if we have vfs support for them)

There's no reason why we couldn't do both.  xattrs on volumes that
support them, then transition to XMP sidecars if the VFS notices we're
trying to copy/move them to a volume that doesn't.

> > 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.
> 
> yes with certain file types - my point is its not a *universal*
> solution.

There is no universal solution.  Storing things in a database breaks
down when I want to fix a typo in the artist tag of an mp3 I downloaded.

> not really a notification should pass the new value for the specific
> metadata in the signal so apps dont need to work out which metadata has
> changed or force them to refresh everything. I dont think thats possible
> without a daemon? (you would need a copy of the old metadata to work out
> whats changed)

Passing the new value is easy, because that's what's now in the
file/database.  Reparsing the file might be a pain for some file
formats, so I can see how a daemon would improve the caching there.

> (3) would potentially be an enormous db - it wont be practical to do
> that and as above places too much burden on the apps (again you need the
> old metadata to work out whats changed). Its kind of going to extreme
> lengths (and pain) to avoid having a daemon to me but then thats just my
> opinion!

I don't think the size of the DB will affect things too much.  If you
add an index on the changed-time column, updates will be infrequent
enough that the overhead at insert time will be small, and the overhead
at search time will be nonexistent.

I admit I haven't prototyped it though, so it might end up being
untenable and a daemon unavoidable.

> the other reason for a daemon is its safer on broken nfs if only one
> process ever writes to the db at a time

Yep, that's a good point.

Joe