Re: [Tracker] Proposed future for Tracker - Smaller modules

[Philip Van Hoof <philip codeminded be>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 9/09/2014 18:54, Martyn Russell wrote:
> On 08/09/14 17:46, Philip Van Hoof wrote:

[cut]

> > No reason. libtracker-sparql users shouldn't care.
>
> Off the top of my head:
>
> 1. To provide a DBus interface (may be a legacy reason, but ...)

Only GraphUpdated is of concern here. That should indeed stay and is a
difficulty in my idea indeed.

The Query and Insert D-Bus DBusMessage based API should at all costs
be completely avoided. They are cruelly slow and shouldn't at all be
called official API (legacy or not, the legacy is btw from before the
0.8.x release, we've had a major version increment since then).

> 2. To provide concurrent connections a way to serialise updates

Is an implementation detail of libtracker-sparql

> 3. To provide a central and singleton authority to the DB schema

That's what I want to change in my utopian idea :)

> 4. Because of database locking mechanisms employed by SQLite?

Implementation detail of libtracker-sparql

> 5. To avoid possible race conditions?

Implementation detail ..

> The last two could be wrong, its been a while since I had to care
> about this stuff :)

The list mostly correct. tracker-store exists for the purpose of:

- - Initiating the ontology
- - Applying ontology changes when detected
- - Journalling when enabled (which shouldn't be)
- - Providing the Backup and Restore API
- - GraphUpdated signal (signals on changes)
- - Steroids FD passing D-Bus API
- - SQLite WAL checkpointing
- - Gathering and returning statistics over D-Bus
- - Receiving over Steroids FD passing D-Bus API the from libtracker-
  sparql rerouted write queries

Except for GraphUpdated it has no API that isn't an implementation
detail or an internal affair of how libtracker-sparql works.


> I'm sure many of those things can be improved these days, but
> you're talking about making this decision upon some utopian idea
> that is not implemented yet. I am talking about doing this for what
> we have *now*.

That is fair enough. But changes we make *now* should not conflict
with these utopian ideas. So let's not split the project, packages and
build files up in such a way that a independent libtracker-sparql with
an independent ontology package and project can exist.

A libtracker-sparql can exists without an ontology installed: the
application that uses libtracker-sparql could provide it all by
itself, and libtracker-sparql would still have purpose.

Just like how libsqlite doesn't come with a SQL schema, instead the
applications using libsqlite provide it.

> > > Consider the application that only wants to query and not
> > > update the DB - they don't want to depend on all the crap
> > > needed for updating the DB, just the raw libtracker-sparql
> > > part.
> >
> >
> > Except that they already and always depend on tracker-store. You
> > can't avoid it (read libtracker-sparql's initialization code: you
> > always and necessarily depend on it).
>
> I guess it depends on what level you care about "depending" on
> something.

Hard dependency. Unavoidable.

Kind regards,

Philip



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (MingW32)

iQEcBAEBAgAGBQJUD3HNAAoJEEP2NSGEz4aDwoQH/15HZMdxABgnpBhd9irSvqSO
g8gkp1qkUroQyx5w8gjIo7G6kZfEc9h1EpIqMI5QJjhgL0wJwXhLqzWgfJVyKul7
bTRxYEJQvj2qc/qYt/JijpRYJxm4PWGo1G+FhdKnxMti88+QK2JnwzPNOrO/pX1D
83oInyQwd3t+U6o5zqxQ3VVn0qcLVZWClVPUDHSjVa9BWIEy7tfpzY++xyhYRH3y
yhSQE+0hiNgRJLsN1+mjr8ACBOFmWXYKhEh+tCz43uMcggN69QuiBncT2h9nvCF1
0AhyH8Bc1BgjHoZp3XFtX8x7LnNBX3QbTWyEFEjnQdf2/CBgSLDQtRrUm52+vDQ=
=ftvw
-----END PGP SIGNATURE-----