Just. Awesome.
On Mon, 2017-06-26 at 00:11 +0200, Carlos Garnacho wrote: > Hey :) > > A general update for everyone, I do consider this ready for merging > and I think I'll do early next week unless I see glaring bugs. All > tests pass, tracker does still behave as it ever used to by default, > there's some documentation, and I put the branch to practice in: > > https://people.gnome.org/~carlosg/gnome-news.flatpak > > If you want to try just do: > flatpak --user install --bundle ./gnome-news.flatpak > flatpak run org.gnome.News > > You will see in ps: > $ ps -ef |grep tracker > carlos 26673 1404 0 18:08 ? 00:00:00 bwrap --args 13 > /app/libexec/tracker-miner-rss -d org.gnome.News > carlos 26680 26673 0 18:08 ? 00:00:00 bwrap --args 13 > /app/libexec/tracker-miner-rss -d org.gnome.News > carlos 26681 26680 0 18:08 ? 00:00:00 > /app/libexec/tracker-miner-rss -d org.gnome.News > carlos 26687 1404 0 18:08 ? 00:00:00 bwrap --args 13 > /app/libexec/tracker-store -d org.gnome.News > carlos 26694 26687 0 18:08 ? 00:00:00 bwrap --args 13 > /app/libexec/tracker-store -d org.gnome.News > carlos 26695 26694 0 18:08 ? 00:00:00 > /app/libexec/tracker-store -d org.gnome.News > ... > > which are the sandboxed tracker processes spawned to handle the > gnome-news data. gnome-news requirements outside the sandbox can be > made to be quite minimal, eg. no r/w access to the user homedir > whatsoever. > > > On Sun, Jun 11, 2017 at 7:19 PM, Philip Van Hoof <phi...@codeminded.be> wrote: > > On Tue, 2017-06-06 at 20:42 +0200, Carlos Garnacho wrote: > >> Hey hey, > >> > >> During the past week I've been continuing the stuff that Philip > >> started on wip/domain-ontologies. I pushed my current progress on > >> wip/carlosg/domain-ontologies: > >> > >> https://git.gnome.org//browse/tracker/log/?h=wip/carlosg/domain-ontologies > > > > Great! I'll keep an eye on the upcoming changing. Maybe I can soon help > > out here and there. > > > >> So far it's shaping up nicely, private databases are possible there > >> through the public tracker_sparql_connection_local_new(_async) calls, > >> xsd/dc/rdfs/nrl/nao are the are loaded from GResource and are the base > >> ontology, the local connection will run a dedicated thread for > >> updates, in a very similar fashion to tracker-store itself. > > > > Wow, nice progression! > > Thanks :), there was enough peer pressure already :p, flatpak has been > a thing already for a couple of years and Tracker was an important > missing piece. People just has been allowing sandboxed apps to talk to > org.freedesktop.Tracker1 which is far too coarse. > > > > >> My topmost > >> items in the todo now are: > > > >> - TrackerDataManager (and many other subsystems) is still a singleton, > >> which doesn't play nicely if you can now create multiple connections > >> that require it differently. I'm halfway into having it be an > >> object/struct so each connection can get its own instance. > > > > Aha, I was at first thinking or planning to simply start multiple > > tracker-store processes. But maybe when TrackerDataManager isn't a > > singleton anymore then one tracker-store could host multiple databases. > > Yeah, I've actually gone that way wrt tracker-store. You can get > separate tracker-store processes each managing its own locations. It > is indeed feasible with this work to have a single tracker-store > process exporting several dbus objects, it's just a combination I > don't see many gains with. You have to teach everything else to talk > with multiple objects, and doesn't bring many benefits to multiprocess > approach. > > But FWIW I actually finished this item. I don't think it's as > important from the service pov as it is from the API one, mainly for > not having it limited to one single global TrackerSparqlConnection for > everything. Clients or plugins may feasibly create multiple local r/w > connections, although the traditional tracker-store backed one is > still unique. > > > > > And, more importantly, a single client's process could connect to > > multiple different metadata graph stores. > > > > Because it's probably inexcusable to have to expect from a client > > developer to split code up in multiple processes, to connect to multiple > > graph stores. > > > >> - Lots of documentation need to be written around this: how to create > >> new ontologies, data migration concerns, dos and don'ts, ... > > > > Yup. But that's good. Lot's of work for the open source youth ;-) > > > >> - Even if some apps could take advantage of private databases, for > >> some scenarios we do need to make it possible running a standalone set > >> of tracker dbus services for private use. I'm still unclear on how to > >> make it most transparent to apps, probably through libtracker-control > >> API. > > > > nod. Encode a per-application and/or per domain UUID in the DBus path of > > the objects? > > Everything fell more in place with the separate processes aproach, > tracker processes take over the org.example.ExampleApp.Tracker1 > namespace. Teaching the libtracker-bus side about this was minimal, > and flatpak allows for autostarting (and talking to) services within > the same namespace than the app. > > > > > > >> There's of course more items for the longer term, but all tests pass > >> with no functional changes, so seems good enough for an update :). > >> > >> And btw, I still think it makes sense to tag tracker-next as 2.0, and > >> use the opportunity to switch to semver, I do hope it plays out and > >> reduces some maintenance burden in maintaining multiple versions. > > > > Wow, great news. Yeah, semver also has this special rule for 0.y.z > > releases, where you can more freely change y and z during a 0.y.z > > 'milestone' release, than after a 1.y.z release. I guess you could do a > > similar thing going from 1.y.z to 2.y.z. > > > > And indeed, the kind of changes involved in domain-ontologies sound like > > worthy of a major increment. Although it could probably be done backward > > compatible (meaning only a minor increment would be needed). > > True :), and the libtracker-sparql bits indeed are. Still worth a bump > IMHO, domain ontologies and code split involved. > > Cheers, > Carlos > _______________________________________________ > tracker-list mailing list > tracker-list@gnome.org > https://mail.gnome.org/mailman/listinfo/tracker-list
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
