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

[Adrien Bustany <madcat mymadcat com>]

El 24/08/09 03:55, Martyn Russell escribió:
> 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.
I totally agree, but then we have to define our abstract interface...
> > > 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.
Oh ok, I get it :) But here we don't have the choice for now I think...
> > > 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.
Put it on my roadmap
> > > 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.
I'm not sure about what you mean with separate, if you mean one miner =
one desktop file, that's currently how I do it. Be it in a desktop file
or somewhere else (I don't really care), I need for a given miner to
know what type of authentication it's using (that's somehow miner metadata).
> > > > > 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.
Currently the NetworkManager code is ifdef'd in my code. If
HAVE_NETWORK_MANAGER is not defined for valac, then it'll be omitted and
the miner will just try to connect. So nothing to change here (yeah :) ).