Re: [Tracker] Extracting the extractors

[Carlos Garnacho <carlosg gnome org>]

Hey Sam :),

On Mon, May 9, 2016 at 1:40 AM, Sam Thursfield <ssssam gmail com> wrote:
> I've made quite a bit of progress on this. The code is mostly there,
> but i've only done a light amount of testing so far so there will be a
> butt load of hidden regressions no doubt.
>
> I have a couple of open questions:
>
> - is it OK to remove API from libtracker-extract ? I seem to remember
> that we've already done that for the TrackerDecorator changes, and the
> developer docs at [1] haven't been updated at all since 0.16, but
> maybe I'm missing something.

Yes, by all means. libtracker-extract was made private before the
switch to 1.x. That was a barely/ever used extension point, now either
patches to tracker-extract or external TrackerDecorators are the way
to go.

> - is it ever necessary to have a DELETE statement for a corresponding
> INSERT statement in the output of an extract module?  I ask because I
> noticed the miner-fs removes *everything* about a file in the
> TRACKER_OWN_GRAPH_URN graph whenever a file changes. Which is the
> right thing to do, I think, but it does make me wonder why some
> extract modules then do their own DELETEs...

IIRC those are mostly audio extractors which are deleting+adding
artist info per-file, and perhaps other document formats for authors
(that's also mainly why we create deterministic urns for those). Or
are there more places doing that?

Anyhow, I have a kinda mixed opinion here. I'm sometimes of the
opinion that tracker-extract should use its own graph, so we could
tear down metadata without deleting filesystem structure information,
although then tracker-miner-fs would have to gain knowledge about this
separate graph. I still agree in that tracker-extract shouldn't be
dealing with cleaning up the metadata it produces.

> The code is in branch wip/sam/resource, and is mostly ready for review
> now, although i want to do quite a bit more testing to be sure that
> there are no performance or memory leakage regressions.

Thanks, I will try to have a look in the coming days.

Cheers,
  Carlos