Re: [Tracker] Review request : Bridge manager subsystem

On 17/08/09 14:42, Adrien Bustany wrote:
El 16/08/09 14:42, Martyn Russell escribió:
On 16/08/09 09:05, Ivan Frade wrote:

OK, I'll sed s/bridge/miner then :)


Yea, we already have a preliminary DBus API for this. Perhaps we
could discuss this further with you Adrien to make sure the API is
sufficient. Right now the file system miner is the only one we have
to worry about so our API might be a bit vague.
As of today I only need a simple key - value system, as TrackerConfig
does... I also need info like network status, but I don't know if it
would be part of that API too...

Well, we could potentially add code for this, however, *how* we do that is interesting. Since we are cross platform, we can't rely on GNOME technology to do it. I am sure we can do this some how. Perhaps we could look into:

Basically, what it does is
list the available bridges, and call the synchronization method
(Pull()) at a given interval. The default interval is 300 seconds,
is currently shared by all the bridges. It also exposes a DBus
interface which allows to set the Pull () interval and to force a
to Pull() on one or all of the bridges.

Yea, that sounds useful for a miner API.

I agree with Ivan here. Miners should know how and when to pull
data, not be polled from the store. Also the store shouldn't have to
manage miners at all. This "sync" method is currently done by
starting all miners on startup using a desktop file and letting them
run the whole time (instead of exiting after inactivity like we used
(instead of exiting after inactivity like we used to) ->  ok, that's
what I was planning to do, to minimize memory usage on small devices
(hence the dbus activation)... But if it does not fit in the Tracker
model, it can be changed easily (it's actually what currently happens
:-) ). About autonomous polling, that'll allow me to define different
polling intervals (see the "Known issues" section), so it's actually a
good thing.

Well, miners really should use almost no memory anyway and should not be polling or waking up unless there is work to be done either. This might depend on each miner, but for the file system miner, we need to stay resident so we can know about file system changes in real time.

Details :
The object basically lists the available bridges (they all have a
.desktop file in /usr/share/tracker/bridges), and keeps the list in

This part is really interesting, because we need a tracker-applet that
receive information from all those bridges. The idea i talk with
martyn was something like the network manager applet, but instead of
listing networks, listing miners and their status.

Yea, the way we planned to do this was by using the DBus API to get
a list of names with the Tracker prefix for miners and expect them
all to have the same base class API (pause/continue/get_status/etc).
yep, that's more or less what I do know except that I scan a directory
instead of calling a DBus method to get the list. What program would
be in charge to keep the list of bridges and expose it via dbus ?

No program. The idea was that miners are started from .desktop files on start up and kept alive the whole time. Carlos and I discussed this yesterday. The applet that lets the user know what is going on with miners would only list miners that are running. Any other miners wouldn't be listed (initially). We could get around that by crawling the dbus services directory to see what other org.freedesktop.tracker.Miner.* services are available but not running and show those in a unique way of course.

I don't think we need a management binary for all miners. Ultimately they should *each* know how and when to get their data and the only thing that matters after that is the user being able to start/stop/pause/etc them.

Nice, I will take a look this week some time.
Note : As I *still* don't have internet at home, contacting me by mail
will surely be more efficient than IRC for questions


Ivan, we currently have libtracker-miner in a separate branch which
we are working on. It will have that DBus API shared amongst all
miners and also the file system crawling basics for those miners
which need to crawl some directories for their data.

We could include some more stuff in there which makes sense for>  1
miner (i.e. shared APIs).
I have a libtracker-bridge which does this, as well as exporting
constants like Tracker's DBus name etc... Sounds very similar :) Maybe
I should merge with libtracker-miner ?

Yes, I will be looking into this this week.

Thanks again for taking the time to feedback :)

Thanks for working on Tracker ;)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]