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