[Tracker] Tracker and removable devices
- From: Sam Thursfield <ssssam gmail com>
- To: tracker-list gnome org
- Subject: [Tracker] Tracker and removable devices
- Date: Fri, 29 Jul 2011 17:36:21 +0100
Hi everyone!
I just posted a patch to add an ipod/iphone miner to Tracker:
https://bugzilla.gnome.org/show_bug.cgi?id=655577
I'm sure there's immediate issues with the patch (these can go on
bugzilla I guess) but also I found some more fundamental limitations
that led to a bit of code duplication, I think because the idea of
filesystem mounts being crawled by miners other than the FS miner
hasn't been explored before. Shall we assume that there will always be
devices in the world that appear as mounts, but actually can't be
treated as a normal file system and need some sort of device-specific
miner? If so, and we anticipate more miners like the ipod one coming
along, perhaps we should think about doing some of these things, which
would improve the code in the apple-device miner and future similar
ones.
* Currently tracker:Volume information in the datastore is managed by
the tracker-miner-fs process. It would be more useful if
TrackerStorage handled this directly, so the device miners could share
this code. The stale volume removal is also done by tracker-miner-fs
at the moment I believe - surely it would make more sense for the
datastore itself to take care of this?
* Also, multimedia players are explicitly ignored in TrackerStorage at
the moment, I presume this is because of the lack of handlers for
them.
* The device miners could do useful stuff like add serial number info
to the tracker:Volume device so we can tell if we have seen a device
before but in a different mountpoint. For the iPod one I also would
quite like to add an annotation with a hash of the database of some
sort so we can easily identify if it's unchanged and the device
doesn't need reindexing.
* It would be useful if the device miners could tell the FS miner to
ignore a particular volume. I guess this could be done with a DBus
call to tracker-miner-fs. I suppose we need to handle the FS miner
having crawled the volume anyway, but with the nie:dataSource
attribute the device-specific miners should be able should be able to
recognise the resources the FS miner found.
Also, though this isn't specific to removable device miners,
TrackerSparqlBuffer looks really useful but currently takes a GFile.
It would be useful to make this and TrackerTaskPool useful for all
miners, not just the filesystem crawler.
So if having more device-specific miners is indeed desirable, this
seems like the best way to allow for them. Of course I'm only looking
at the problem from one angle, and I of course can't wait to hear all
of other things that could be done and reasons the above isn't
possible and won't work :)
Thanks
Sam
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]