Skip to content

Tracker 3.0 API changes

Carlos Garnacho requested to merge wip/carlosg/tracker-3.0-api-breaks into master

(Marked as WIP, as functional tests don't pass yet. Still good to stir up discussion)

Notable changes in this branch:

  • tracker_sparql_connection_get() sync and async API is gone. There is no singleton anymore, and connections are obtained through explicit constructors: tracker_sparql_connection_new() for triple stores managed by the current process, tracker_sparql_connection_bus_new() for dedicated connections to a dbus service, and tracker_sparql_connection_remote_new() for HTTP endpoints.

  • tracker_sparql_connection_local_new() is also removed, essentially superseded by tracker_sparql_connection_new()

  • TrackerEndpoint and TrackerEndpointDBus got properly hooked up. On the service side, it gets able to proxy a TrackerSparqlConnection, and notify changes on it through an internal TrackerNotifier. On the user side, the bus-based TrackerSparqlConnection (and SERVICE syntax) will be able to talk to endpoints, and TrackerNotifier may be used to track changes in remote services.

  • TrackerNotifier is now created through a vfunc in TrackerSparqlConnection, this is so notifiers can be set up differently depending on the source connection type.

  • load/statistics API is removed, as there means to do all that with SPARQL.

  • tracker-store is removed! By giving users control over stores and endpoints, the plan is to decentralize data. tracker-miner-fs will have it's own endpoint, and so should anyone interested in storing any rdf data.

  • TrackerSparqlBuilder is finally gone too

  • API exposure has been tightened, the branch uses GNU symbol visibility to have symbols hidden by default, and explicitly made public.

Not covered in this branch:

  • Sandboxing: This stands as the next step. It may involve changes on the DBus communication layer, but that's no longer deemed API, nor API changes are expected.

Some things that might be good to get feedback:

  • tracker_sparql_connection_get() removal is maybe a bit too harsh. I stand in the opinion that it doesn't make sense where we are heading to, but perhaps having it talk by default to tracker-miner-fs could ease transition, but access to that endpoint should turn readonly at some point.

  • Functional tests are still broken, boils down to trackertestutils offering methods to spawn a tracker-store and talk to it, but 1) tracker-store not existing and 2) DBus endpoint API not being as convenient for simple wrapping (eg. relies on fd passing). Could be worked out, but keeping this infrastructure feels a bit out of place.

  • A tracker store CLI subcommand might be useful to create transient stores (eg. for functional tests in the point above).

Edited by Carlos Garnacho

Merge request reports