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
Attachment:
signature.asc
Description: This is a digitally signed message part