Re: [Tracker] Discussing the API of libtracker-miner

[Martyn Russell <martyn lanedo com>]

On 18/08/09 20:30, Adrien Bustany wrote:
> El 18/08/09 07:00, Martyn Russell escribió:
> I'm won't copy Philip's answer here, but yes if it's to extend an
> existing codebase I don't mind coding in C at all (I just code in Vala
> 'cause it's faster, and using DBus from C is sometimes painful).

OK.

> > I think the authentication part will be the hardest part to figure out
> > for cross platform working and also for the Maemo platform which
> > doesn't use GnomeKeyring either (AFAIK).
> Yep, that's why from day 0 I hided the gnome-keyring implementation
> behind an interface... Mikkel's link is pretty interesting, although
> maybe a bit overkill for us. To me, the model where you have an
> identifier associated with a secret + a set of attributes is pretty
> simple, and should work everywhere. But yes, maybe we should discuss it
> more.

This is interesting from the point of view of Maemo and KDE I suspect. I 
have no problems including it if it only works for GNOME at this point, 
but we should consider that it alienates itself on other platforms until 
there is a mechanism in place to support those too right now.

> > Yes, I have used this in Gossip before too, it is fairly straight
> > forward, but I don't think we can use NetworkManager in Maemo and I
> > don't know if KDE use it. We can probably use some other low level
> > tricks to know if we have a connection. Any suggestions?
> PackageKit had the same problem... I don't exactly remember how they
> solved it, but I can have a look at the codebase. KDE uses
> NetworkManager (via another interface called Solid IIRC), and on maemo
> we can use libconic (and connman on Intel's distro). Again, as long as
> we abstract things behind an interface, I think we solve the problem
> (but maybe I'm too optimistic ? :) ).

Yea, abstracting this is something I would prefer to avoid. Perhaps we 
can't though :/

For now, get it working and we can improve that situation when the time 
comes. If abstracting it is quick and easy, then I would go ahead and 
just do that.

> > Again, this is problematic and needs some consideration. Ivan do you
> > have any ideas about how this would work on the Maemo platform?
> http://maemo.org/development/documentation/apis/4-1/ doesn't mention
> anything about password management,
> http://maemo.org/development/sdks/maemo_5_api_documentation/ either at a
> first sight. Needs confirmation though.

Ivan, anything you can add here?

> > > 4. Configuration storage
> > > It'd be nice for all the miners to have an easy API to store key/value
> > > tuples. I've been told Martyn is working on it...
> >
> > Well, we have tracker-config-file in libtracker-common and
> > tracker-keyfile-object with some convenience APIs, but it is all in C,
> > not vala. You can see how we have done tracker-config in
> > tracker-miner-fs and how we use those APIs there.
> Yep, actually I used this for the tracker-subsystem, which is in vala (I
> wrote a very simple vapi file). To me that system is powerful, but
> adding a new setting is not that simple (needs to modify the private
> structure, the object properties, write getters and setters...). I'd
> rather advocate for a GKeyFile like API.

OK.

> > I should continue here with our current plans for the miner APIs:

Just so you know, the API here has changed slightly.

> > Methods:
> >
> >   * gchar * get_status()          - any string
> human readable ?
> >   * gdouble get_progress()        - 0->1 or -1 if not supported
> ok, I have this in my current interface although no bridge^Wminer uses it.
> >   * void    pause(gchar *reason)

Pause is now:

     * gint    pause(const gchar *application,
                     const gchar *reason)

Where the return is a cookie to resume. This allows multiple pausing 
which we found we were doing in 0.6.

> >   * void    resume()

As you can imagine, resume now takes the same cookie you were issued with.

> >   * void    start()
> >   * void    stop()
> looks fine to me
> > Signals:
> >
> >   * started()
> >   * stopped(gboolean interrupted)
> >   * paused(gchar *reason)

I will probably update this based on the new API too.

> >   * resumed()
> >   * progress(gchar *status, gdouble progress)
> >   * error(gint code, gchar *reason)
> in my solution, all miners install a .desktop file in
> $(datadir)/tracker/bridges (should be changed to miners) containing the
> name of the miner, as well as its dbus name and path (and some other
> information only useful for web miners). I use this solution because it
> allows a single process to have several miners, useful for example for
> the twitter one (which does identi.ca as well) and the google one (does
> only picasa, but could do other things).

I am not sure I understand why you need to use $datadir/tracker/bridges? 
I mean, we use .desktop files and .service files for dbus activation. 
Also the default tracker-miner-fs will provide 2 miners anyway (one for 
applications and one for files). So is there something more you need here?

> > Did I miss anything?
> if we sort out all the issues raised in this thread, then this will be a
> good progress :)

Did you have a chance to look at the branch we are working on yet? It 
would be great if your code could work with the miner "shared" API - we 
could look into merging the work into the branch too at some point.

--
Regards,
Martyn