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 <phi...@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 _______________________________________________ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
