-----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----- _______________________________________________ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list