Re: [Tracker] Domain ontologies

[Sam Thursfield <ssssam gmail com>]

Hi Philip,

This is interesting work, and looks like a sensible design if what
people want is more tracker-store instances and more shared databases.

I wonder myself if there is demand for that. I don't think many app
developers work from a "first, how can I ensure all the app's data is
shared" mindset. And that's probably correct, because until the app is
stable there might be incompatible changes in the way it stores its
data. Eventually standards emerge and at point there's an argument for
a shared data store so that multiple apps can access the same thing,
but I don't see many people actually asking for tools to do that. The
apps that I'm aware of use Tracker today mostly use it as a filesystem
indexing tool, not a way of combining their nmm:Photos resources with
some other apps' nco:Contact resources.

So I'm more interested in making tracker-store usable as a library
(without breaking existing stuff), and I think that's something that
this branch makes easier ? Certainly being able to specify different
sets of ontologies and a different database location is useful.

On 1/29/17, Philip Van Hoof <philip codeminded be> wrote:
> All this obviously needs fine-tuning, bike-shedding over key names,
> parameters and command line parameter names, concepts and how to
> integrate with DBus .service files. There should probably also be a
> --list-ontology-domains, I guess? Yes, sure.

I actually think the names are fine :-)

...

> And I guess flatpak can specify which flatpak has rights to which
> domain-ontology, so that the libtracker-sparql clients running in that
> flatpak can access the right files and directories and DBus paths and
> services that they need, to query a specific domain-ontology.

That sounds interesting, can you give an example of what groupings we
might have though? I feel like in practice we'd just end up with each
app only able to access its own data, at which point the data doesn't
really need to be outside the sandbox. Although I suppose it allows
for a kind of "mega-tracker"  search provider that provides results
from every domain ...


> ps. Other ideas: support that a tracker-store process can support
> multiple ontologies and multiple domains? Sounds like overkill to
> support but might be nice (in terms of correctness of the code) to make
> this possible someday. Right now there are a few global variables and
> singleton-like concepts, in tracker-store, that don't make this
> possible. They shouldn't be there in my opinion (= that's just quick and
> dirty code, not a good design or a indented concept in tracker-store's
> code - so you can and should just fix this if you feel like doing so).

Yes, this is what I'd like to do :-)

So, I guess we have slightly different solutions in mind for "Tracker
meets Flatpak", but I think they actually don't conflict at all and
could even probably be done in the same branch. If I get time to work
on Tracker any time soon I will see if that's indeed the case :-)

Sam