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! > 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. 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? > 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). Super to see work on this progressing! 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
