Hey Sam :), On Mon, May 9, 2016 at 1:40 AM, Sam Thursfield <sss...@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 _______________________________________________ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
