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

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


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

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? doesn't mention
anything about password management, 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.


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

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


  * 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


  * 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 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.


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