[Tracker] The Utopian idea, Tracker as it should be

[Philip Van Hoof <philip codeminded be>]

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

So on IRC ssam2 and martyn were discussing this and then asking me if
what they concluded was something I agreed with. So one more time :-)

My idea is this:

The SPARQL Endpoint
- -------------------

o. libtracker-sparql and tracker-store get merged together. Perhaps we
   rename libtracker-sparql, perhaps not, perhaps it doesn't matter.

o. Instances of tracker-store become managed by libtracker-sparql
   (through D-Bus service activation or not, it's an implementation
   detail of libtracker-sparql either way)

o. Nepomuk becomes an upstream project, managed separately

o. Applications that need to deal with metadata will depend on Nepmuk
   (managed separately) and libtracker-sparql. Just like how they could
   if they'd use SQLite depend on libsqlite and on their own DB schema

The mining of metadata
- ----------------------

o. The 'Tracker' project will contain only miners

o. The miners will depend on Nepomuk (managed separately) and
   libtracker-sparql (like any other application) and on tracker-extract

o. tracker-extract gets a public API (DBus FD passing based) that isn't
   deeply coupled with tracker-miner-fs

o. tracker-extract therefore becomes a separate project (applications
   that want to use it can depend on it, without having to depend on
   Tracker's other miners). It deals with metadata so it too depends on
   libtracker-sparql and on Nepomuk (managed separately) (like any
   other application)

o. tracker-miner-fs accepts (in implementation) that others can provide
   metadata (by integrating with tracker-extract or not) and that it
   should not interfere (this is already somewhat in place by using the
   graph support - our insert-or-replace sentence already only replaces
   in our own miner-fs' graph only, giving precedence to other graphs)
   It deals with metadata so it too depends on libtracker-sparql and on
   Nepomuk (managed separately) (like any other application)


Why, my god, whyyy?
- -------------------

libtracker-sparql + tracker-store: Allowing multiple ontologies to be
  used. Applications don't care about tracker-store. They just want an
  API to launch their SPARQL and SPARQL INSERT queries on (and that's
  really it). They also want GraphUpdated, which is problematic as this
  would need to be separate per ontology too (fair enough).

tracker-extract separate: Allowing MTP daemons to enrich metadata
  themselves on a file in /tmp before doing the rename() to the final
  destination in $HOME. Allowing them to control the metadata insertion
  instead of letting inotify of tracker-miner-fs picking up the file
  after rename (metadata upfront the file being ready). To indicate
  that the file isn't ready we have tracker:available property.

Nepomuk separate: Sharing the ontology with KDE desktop, without
  GNOME's politics interfering of trying to dominate needlessly the
  processes (which, whether GNOME people like this or not, would imply
  that KDE simply wouldn't use it). Where this gets hosted? FDO?
  nepomuk-desktop.org? Jesus, I don't care.

  I also don't only care about the desktops. There are industries like
  Automotive, File Sharing solutions, Digital setup boxes for digital
  TV and portable harddisks using Tracker right now. They all want to
  influence the ontologies. A consortium that is more neutral than "the
  Linux Desktop world" is needed. Being wrong is bad, as it's always an
  API change (all depending projects need a major version increment and
  things start breaking at the query level).

  So we outsource this to a more competent team who care about more
  than like we do about just our implementation of it.


FAQ
- ---

Q: Would this be a split of the project?
A: Yes, I guess. In four parts (Nepomuk, libtracker-sparql, tracker-
   extract, tracker(-miners))

Q: Does it matter?
A: No, I guess (we'll still love each other on #tracker and
   tracker-list. Same maintainers, same overall project, same goals)

Q: Are you dangerous? Splitting is bad! bad bad bad! You witch!
A: Very

Q: But I use tracker-store's Resources DBus API to do Query and Insert.
   And you want me to use libtracker-sparql then, rigth? Will that make
   my beloved DBus API on tracker-store disappear?
A: Yes. You should never have used that one in the first place. The
   only public API that we should support is libtracker-sparql (and
   GraphUpdated on Resources, but I guess we'll bring that as a signal
   on the TrackerSparqlConnection to libtracker-sparql too)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (MingW32)

iQEcBAEBAgAGBQJUGXuDAAoJEEP2NSGEz4aD+QgH/iPmdhfJE0MnPD87pwlocQqR
/8/Mje1LudXfj8h/yospxYvceqnhu1ypO+Pi5DQ+0EXVyzoqfpuh19elX6XMUOx9
6N3ui3vQXuEBjL/VAIF/FTM0G/6wPc5Aq5frwxjNHfap+8Hj0YhNJUZwhL9Q/d1K
hUn99nymn1Q4wAQqC1EStX/j8YNees8lJtQ+t4RJZ8FkygiZuZoBjCdMPmBvJ2HL
OIEZ4HfXsMQmg2jQW6z0X09lDz23IWB7kXanYj/yHCQgCyl6qN39F564KLoG2VyA
PVNYzuZKWljmMTVfjojv8BCFfLspGr4FsniR1qYbcavXWf7+WWj7pTFntRow6Aw=
=Vb6H
-----END PGP SIGNATURE-----