On Tue, 2017-02-14 at 23:53 +0000, Sam Thursfield wrote: [cut]
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 can imagine music softwares would form a group, photo softwares would form a different group. And I guess music softwares and video softwares would share a group.
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.
Initially probably yes.
Although I suppose it allows for a kind of "mega-tracker" search provider that provides results from every domain ...
Yep. The default ontology-domain will probably run on the host that runs the desktop session, and provide access to metadata to flatpak sessions running in containers. But a particular flatpak-session could become the provider of a different 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 :-)
Go ahead! :)
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 :-)
Yep, let's work on this in the same branch. Sounds good! Low hanging fruit is sharing the code for reading the GKeyFile between tracker-store and libtracker-sparql, and using the code in libtracker-sparql to pass the parameters needed for DataManager.init. Kind regards, Philip
Attachment:
signature.asc
Description: This is a digitally signed message part