-----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
