Re: [Tracker] Review request : Bridge manager subsystem

[Martyn Russell <martyn lanedo com>]

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:

  http://git.gnome.org/cgit/gnio/

> > > > 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,
> > > > and
> > > > is currently shared by all the bridges. It also exposes a DBus
> > > > interface which allows to set the Pull () interval and to force a
> > > > call
> > > > 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
> > to).
> (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
> > > > memory.
> > >
> > > 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

OK.

> > 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 ;)

--
Regards,
Martyn