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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
