Re: [Tracker] Problems with removable volume support

[Martyn Russell <martyn lanedo com>]

On 13/03/14 12:04, Jürg Billeter wrote:
> Hi Philip,

Hi all,

> On Thu, 2014-03-13 at 12:54 +0100, Philip Van Hoof wrote:
> > Some platforms don't use udisk2 and/or gvfs so they fall back to the
> > implementations behind gio/gunix*c. These implementations aren't
> > always very reliable. In particular is the UUID of the volume not
> > always correct with those implementations. It would be nicer if we
> > could let something external to tracker-miner-fs fed us with that UUID
> > and mount point name upon mount event, rather than using GVolumeMonitor.
>
> I don't see why we would need an abstraction layer in tracker for this.
> GVolumeMonitor is a GIO extension point. If there are platforms where
> the gvfs/udisks2 implementation is not suitable, a platform-specific
> implementation of GVolumeMonitor can be used. This should not require
> any changes in tracker. That way, all GLib-based applications can
> benefit from it.

I agree with Jürg here, I would prefer this was in GIO or lower and 
reusable for all, but perhaps you meant something else with your idea 
about an external entity for volume management Philip?

I certainly mentioned an idea to have a process dedicated to handling 
removable devices and 3rd party services which can appear as easily as 
they disappear. Is this what you had in mind?

For the benefit of others not on IRC, the idea was to simply monitor 
such events (like mounts added or removed) and round-robin emit a signal 
to all listeners (a bit like we do with GraphUpdated - so over DBus) and 
if there are any interested parties (wanting the content), we index. 
That way we avoid this entire 'index all' or 'index none' or 'guess what 
to index' with devices that we currently have. In a lot of cases, people 
either disable indexing removable devices entirely OR they just add the 
location to the list of directories to index anyway. This idea is like a 
half way house between automatic indexing and application requested 
indexing of content. We could then cache such a list of devices and 
application's interest there so we know how/when to clear this cache.

The entity here would essentially be in charge of maintaining the data 
in the DB for those devices, setting tracker:available on the right 
sources, etc.

You might ask: why not do this in the miner-fs? Well, there are some use 
cases of Tracker that include indexing online 3rd party cloud data, (a 
duplicate if you will, of the data) in Tracker for a centrally 
searchable DB. In these case, we don't have a solution for maintaining 
all of those 3rd party data components and it's really up to each miner 
to handle their own a) graph, b) data-store properties on resources and 
c) tracker:available properties. Probably a host of other things too 
(tracker:added, etc)...

Anyway, it's just an idea at this point :) if there are comments, I 
would be interested to hear them.

--
Regards,
Martyn

Founder & Director @ Lanedo GmbH.
http://www.linkedin.com/in/martynrussell