[Wasabi] Kicking of the Metadata spec - brainstorm

[jamie]

> > 
> > 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.)
> 
> (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!

let me give you a good example of why this is suboptimal

suppose :

1) nautilus is listening for all metadata changes in files in folder X
only

2) F-spot is listening for metadata changes to photo files only

3) RB is is listening for metadata changes to music files only

lets suppose (2) updates a tag, (1) and (2) would have to re-query the
DB using timestamps and get back a tag. They would both have to
determine if this tag is relevant to them and then hence do all the
work. Also those apps would be continually awoken whenever anything
changes (bad for batteries). This clearly is not a scalable solution
when you start having more than a few apps.

now lets look at above with a daemon:

(1) would use a subscriber interface that only gets notified for
metadata changes to files in folder X


(2) and (3) do likewise but for photos and music

this way, only the apps get awoken when necessary and they get the
metadata change they need (without out any work involved). Its efficient
and scalable too.