Re: Common music database?

Milosz Derezynski wrote:
> Oh yeah the reason i asked for HAL inclusion (although this should be 
> also discussed on xdg list i take it, but TBH the xdg list is just dead 
> and alot of xdf people are present here just as well) is that BMP uses 
> the HAL device and volume UDI to make only *those* files accesible and 
> visible to the user that currently _are_ accessible.
> 
> I.e. you start BMP, add 2000 files from your usb harddisk, unplug the 
> usb harddisk, and they are hidden in the library cause they're just not 
> accessible; the mount point of this harddisk doesn't matter and it can 
> change, all that's important is the HAL UDI
> 
> (If someone goes about to argue HAL doesn't have UDIs for everything 
> yet: right. If someone goes about to argue that a HAL UDI is 
> "unreliable": Not really. It's for one more reliable than a mountpoint, 
> given that the device and volume UDI stay the same, and if they change 
> (i.e. you get a new volume UDI for the same device UDI) you can with 
> sane reason assume it's a new volume, i.e. it got formatted or it's 
> another partition of some harddisk).
> 
> The paradigm here is "We're not talking about missing files yet, but 
> first about a missing device": BMP will also not prune files from the 
> library (when asked to prune it) whose device/volume is currently not 
> plugged, as it's not reasonable to say that "they aren't there anymore". 
> They can be very well "there", just on a device that's not present. 
> That's the same as you can't tell if Daisy has got her hair colored red 
> if she's currently not at the party. Heh.
> 
> Well a little more information is on our Codeblog: 
> http://blog.beep-media-player.org/?postid=2 (Note that this has been 
> rewritten to use HAL instead of sysfs directly)
> 
> Jamie: Please add this to Tracker! Maybe not make files invisible 
> completely when the device and volume aren't there, but give them a 
> boolean type flag that indicates that for every file, so that this is a 
> wholly optional issue.
> 

Okay, thought about this a lot more.

I believe the best way to deal with this in Tracker is to treat those 
files as virtual (VFS style). SO maybe you could define a URI for it 
that includes the HAL device, volume UDI and relative path of the media 
file (HAL://UDI/media.ogg) and then attach metadata against that uri.

It makes no sense to store the full path including mount point as that 
will obviously change and you need the full path in order to identify 
the file and get/set metadata anyway so a HAL uri would make much more 
sense here.

As I said before, Tracker treats virtual files as simply a string ID 
with which you can attach metadata to but it will not automatically 
extract metadata from it so you will need to manually populate Tracker 
with any metadata you need (including File.* stuff like mime type as 
well as any Audio.* stuff) and this goes for both Gnome-VFS, KIO-slaves 
as well as any arbitrary uris like HAL.

The media apps might *optionally* have to do a stat() dance on removable 
devices and VFS mounts to check everything is there in those cases and 
inform Tracker to delete any files/metadata that no longer exist.

I will also adjust search functionality so you can specify whether to 
include virtual files in the search results.

Hopefully this will be a more satisfactory solution?

jamie.

-- 
Mr Jamie McCracken
http://www.advogato.org/person/jamiemcc/