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