-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/03/2015 11:27, kunaal jain wrote: > I couldn't find reference to per-app databases. What exactly it > is? Why do we need it?
When tracker-store, libtracker-sparql are bundled as one package (as libtracker-sparql for example) and data/ontologies is bundled as Nepomuk, and tracker-store+libtracker-sparql gets a few small adaptations to allow it to load an ontology from a by-API configurable location (and store its DB in a by-API configurable location), then libtracker-sparql could be used like how libsqlite can be used: a database and schema per application (or per group of applications). Right now Tracker has a more monolithic approach, meaning that it comes as a single package with one ontology (and the miners). o. The miners should depend on libtracker-sparql and Nepomuk o. libtracker-sparql gets bundled with tracker-store (they are not separately usable anyway) o. The Nepomuk ontology should be shipped separately o. The Nepomuk ontology should be made replaceable (so like schema's of relational databases) - API additions to libtracker-sparql - Allowing tracker-store to boot a ontology from a passed parameter as location - Allowing multiple tracker-store instances to run - Allowing libtracker-sparql to configure to which tracker-store to connect - Means allowing multiple meta.db instances - Helping packagers get the dependencies right - Documenting how application(-groups) should use this > Regarding the shifting, making new repos, repacking of codes and > all, I think you guys should decide onto something, as the > discussion was argumentative. I can help in implementation, but > decision making is all yours. The conclusion of the debate was that most people agree. It's just who will do the work :) > Also I found discussion about storing xattr and tags of files. But > in tracker we already have tagging. What is it then? That's an idea of Jürg to replace portions of libsqlite with storage in xattr attributes of files and query using a NoSQL-like solution that iterates over the attributes of those files (instead of SPARQL). But that's quite a innovative idea that would replace most of what Tracker nowadays is. It's not a bad idea. Jürg doesn't produce bad ideas. But it is completely different than SPARQL with Nepomuk. Would more be like NoSPARQL with Nepomuk and deep integration with the underlying filesystem. > I am sorry if I sound stupid, I am new to tracker as a developer. > Much ground to cover. Np. As a Google Summer of Code student you'll of course have to research your subject too and pick your battles wisely. Kind regards, Philip -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJVAXfpAAoJEEP2NSGEz4aDYPsH/jytwuD0doKuvLmFruoUFL3L HN1MrZEGM9oTixt/u8RNxm8WBGKaV4wC5dcV5JeNictVCu4zTF/wCnqhEpV/BJ3C KmMeV3PAMWxBR+na1pdNagi7R05+uG97MK/s9U5Kh0pfDl3gc3MZ0FRnG3jWH4cz 4iRKExcENptWKk9Z/aNody4u4kC/CX8PVStNuXn5PJ4WMdY2NoIvOYp2DVzv+4X2 GR0E+viPHES87eYHBdCDo77uzxkW3NKxsemgTHixgSWG3Md7BF5thL9wRpCDzSY1 jxRtSzKULhj1uRYz4M7aoJODVRCAacvZWopVz4ZiDNpADZAYSE0gVO1kVsHj5Uw= =Pohp -----END PGP SIGNATURE----- _______________________________________________ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list