Re: [Tracker] Proposed future for Tracker - Smaller modules
- From: Philip Van Hoof <philip codeminded be>
- To: Martyn Russell <martyn lanedo com>, Desktop Devel <desktop-devel-list gnome org>, Tracker mailing list <tracker-list gnome org>
- Subject: Re: [Tracker] Proposed future for Tracker - Smaller modules
- Date: Mon, 08 Sep 2014 16:56:09 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/09/2014 12:34, Martyn Russell wrote:
Hi Martyn,
Module = tracker-store - ontology (database schema) - libstemmer
(stemming library used by libtracker-fts) - libtracker-common (type
and various utilities) - libtracker-data (database access and
implementation) - libtracker-fts (SQLite module for tokenising) -
tracker-store (daemon providing DBus interface)
Module = libtracker-sparql - libtracker-bus (DBus and read/write
access to the DB) - libtracker-direct (readonly access to the DB) -
libtracker-sparql-backend (internal implementation) -
libtracker-sparql (public facing library to the DB)
My proposal would be to keep tracker-store, ontology and
libtracker-sparql together (as one project).
The reason for that is that the actual goal of libtracker-sparql was
to provide what libsqlite is for a RDMBS and SQL, but for RDF and SPARQL.
Without tracker-store, libtracker-sparql can't work.
By splitting the ontologies into a separate project, managed by the
Nepomuk organization or not, we could someday refactor
libtracker-sparql to support multiple instances of installed ontologies.
Ideal in that scenario would be that tracker-store becomes an impl.
detail of libtracker-sparql (it'll manage the instances of stores on a
on-demand basis).
The only real three reasons of existence of tracker-store are:
- GraphUpdated
- The fact that SQLite isn't MVCC and we need WAL journaling
and checkpointing done by a separate 'writer' process
- Providing a ontology
When your process links with libtracker-sparql and uses direct-access
mode, it effectively has everything it needs to deal with meta.db.
The eventual dependency tree would look like this:
Your program depends on:
|
+- nepomuk-ontology
|
+-libtracker-sparql
`- Internally uses libexec/tracker-sparql-store
This API:
https://developer.gnome.org/libtracker-sparql/stable/TrackerSparqlConnection.html
Would look like:
#include <nepomuk/2006-2008/ontology.h>
#include <tracker-sparql.h>
static void something ()
{
GError *error = NULL;
Ontology *ontology = nepomuk_ontology_2006_2008_new ("session id");
TrackerSparqlConnection *con =
tracker_sparql_connection_get_for_ontology (ontology)
TrackerSparqlCursor *cursor = tracker_sparql_connection_query (con,
"select ?a { ?a nie:title 'something in nepomuk' }",
NULL, &error);
while (tracker_sparql_cursor_next (cursor, NULL, NULL)) {
g_print ("%s\n", tracker_sparql_cursor_get_string());
}
g_object_unref (cursor);
g_object_unref (con);
g_object_unref (ontology);
}
This would internally deal with starting and stopping a
libexec/tracker-sparql-store, and no global "tracker-store" would be
needed anymore (the fact that multiple users share the same "session
id", creates the central storage for users of that "session id").
Storage could go to:
~/.tracker/sessions/$session-id/nepomuk-2006-2008/meta.db or something
Kind regards,
Philip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (MingW32)
iQEcBAEBAgAGBQJUDcOJAAoJEEP2NSGEz4aDAQQIAJ6arFvREfkh3tvieSwvvPLw
gDo7hP8XUHo42GaWC0bfSIV5cZalgN66zZN2uWjKDRba9zQ76F166lQQJ6l/LmlK
JQA0DvjuEQvLqR52dc8MDaC0H7D0dXFGWT3lhynCUxioyRPipDHVlwE0WlWEkfnR
CGQIeFK7ADgKi4Ae85cxsgJvN0GD3TGwigF10mTSjbLXCwXDyc+XdnBCwx3zFlQ+
H4S2avM3c/DlcPHfudJKy8Bm0qS7YmJxqnOdykkJVYJ3d4TIDf7uOarlkEwuCbxm
HraxGgq7xpT/7mIbUlTbS150cFhG/Q03ceeKkewLtfEcmBOEGuB9BRQFi+wJ8LU=
=4rYt
-----END PGP SIGNATURE-----
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]