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

[Martyn Russell <martyn lanedo com>]

On 21/08/09 17:43, Adrien Bustany wrote:
> > 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.
> Well, KDE offers KWallet, and I don't know about maemo... I don't
> think the API I currently use is Gnome centric, I actually needed some
> hacks to make gnome-keyring fit into it (to store the additional user
> data, though admitedly using GConf would have been cleaner). The basic
> thing we need is a store which does user ->  password (which is I guess
> is the minimum for a password provider). The storage of additional
> (unencrypted) information can be done by the "configuration" module.

Right. As Ivan says here, it is best to keep it abstract then so we can 
support all platforms as best as possible.

> > Yea, abstracting this is something I would prefer to avoid.
> > Perhaps we can't though :/
> Hmm, could you explain that ? (not that I don't agree, just that I
> don't see why abstracting is bad)

It is't bad. It would just be better if there was ONE way of doing it - 
less to support ;) If we have to, let's just abstract it.

> > 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.
> OK, like gnome screensaver does... Fine with me

:) Yea

> > > > * started() * stopped(gboolean interrupted) * paused(gchar
> > > > *reason)
> >
> > I will probably update this based on the new API too.

Please do. If you look at the branch, I have updated tracker-status to 
query all miners and to pause/resume already. If your miners can work 
with tracker-status, that would be superb.

> > 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?
> For the "web" miners I need to know the authentication method (token
> based or user/pass). But the miner description can be stored in the
> same desktop file that's used for activation (well, actually it should).

I still miss the point.

The .desktop files should be in $datadir/tracker sure, but I think 
that's it. The .service files go somewhere else.

Do you mean to keep all miners separate? If so I am not sure it makes 
sense to do that.

> > > > 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.
> I can port my code, but what do I do for network status and
> credentials ? Do I write patches for libtracker-miner ?

Hmm, for now, I would just try to connect and we can resolve that later. 
It should be easy to add after. We will probably have to abstract that 
later too. If you already have it working using NetworkManager, I would 
just leave it like that for now.

--
Regards,
Martyn