GNOME Bugzilla – Bug 615050
Provide API to check whether the daemon is running or not
Last modified: 2010-12-08 10:46:31 UTC
Would be great to have a function that returns state of the tracker daemon (tracker-store), if it's running or not (gboolean result is fine). Probably by checking the name presence on the message bus. The thing is that tracker_client_new() can take a long time to initialize and it's a blocking call. Furthermore, if user has decided to turn it off, we don't want to autostart it again. One option would be to check the name presence on dbus ourselves but as long as we load client tracker lib dynamically, we can't really link to dbus libs by default, adding new dependency. tracker-control.c from the tarball implements this in a different fashion.
(In reply to comment #0) > Would be great to have a function that returns state of the tracker daemon > (tracker-store), if it's running or not (gboolean result is fine). Probably by > checking the name presence on the message bus. This sounds like the best way yes. There is something like this for miners in the libtracker-miner API. I think it makes sense in libtracker-client however for tracker-store. > The thing is that tracker_client_new() can take a long time to initialize and > it's a blocking call. Furthermore, if user has decided to turn it off, we don't > want to autostart it again. True. > One option would be to check the name presence on dbus ourselves but as long as We currently do this internally with is_service_available(). > we load client tracker lib dynamically, we can't really link to dbus libs by > default, adding new dependency. Not sure I follow what you mean here, we currently link with dbus-glib1 already? > tracker-control.c from the tarball implements this in a different fashion. Yes, using /proc, however, it doesn't identify between different versions of Tracker. If at some point we were to use a new D-Bus API version, then that method wouldn't help.
Thanks for your comments. (In reply to comment #1) > > we load client tracker lib dynamically, we can't really link to dbus libs by > > default, adding new dependency. > > Not sure I follow what you mean here, we currently link with dbus-glib1 > already? Yes, that's fine, let me explain: in GtkFileChooser and Nautilus we have different search backends available whose libraries are loaded dynamically at runtime, checking if the libs are available in the system (with the priorities of Tracker, Beagle, simple posix find). These are soft dependencies, but we can't afford linking gtk+ with dbus libs just for the availability testing. Hence, better to have this as a new symbol in libtracker-client.
The question here is why? With libtracker-client, tracker is instantiated for you of course. With the new backends for GtkFileChooser, we now have direct access and dbus access which either uses the store or a library to access the databases. So the status is even more irrelevant than before. Also, now that we're using GDBus too, there are (I believe) methods to find out if a service is running quite easily (I have not seen this myself, just been told). I don't think the developer or client should need to care about the status of Tracker to use it, it should just work. I am marking this as WONTFIX for now, if you have reason to reopen please do so :)