Tracker 3.0 API changes
(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
TrackerEndpointDBusgot 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
SERVICEsyntax) will be able to talk to endpoints, and TrackerNotifier may be used to track changes in remote services.
TrackerNotifieris 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.
TrackerSparqlBuilderis 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.
tracker storeCLI subcommand might be useful to create transient stores (eg. for functional tests in the point above).