Hi, A tracker db per app (or group of apps) breaks the whole concept of "one pot to put everything and link it together". Not that we are exploting much the linking... yet.
It can still have some utility security-wise: the problem of mixing "non-redistributable" information like facebook contacts with what is already in tracker. Or in other words, seen different graphs depending on who is accessing it. Regards, Ivan On Thu, Mar 12, 2015 at 8:34 AM, Philip Van Hoof <phi...@codeminded.be> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi everyone, > > On IRC Carlos raised some initial concerns around the idea of allowing > multiple instances of tracker-store per applications group with > differing ontologies, such as sandboxing, data granularity and > per-volume data. I of course invite everybody to discuss concerns. > > If Kunaal Jain is willing to work on this as a GSoc project, I will of > course create a backlog of tasks and split this up in biweekly sprints. > > Then every two weeks people can during reviews incrementally see > progress and continue raising concerns on the mailing list. > > As mentor my plan is to try to get the reviewed contributions in > develop or master (gitflow or atlassian style) at the end of each two > weeks. If Kunaal Jail does get started on this, I don't plan to tackle > it as a monolithic big change to the project (not like the vstore > branch). Rather, step by step. > > ps. I asked around on IRC to check of others are willing to mentor > this, but the reactions I got so far was that everybody else is > already occupied with other tasks lately. If people want to join on > this, let me know. > > ps. I'm not often on IRC-#tracker anymore because I'm trying to be > less on IRC and more in my garden and 30m deep in the water ;-) > > Kind regards, > > Philip > > > On 12/03/2015 12:26, Philip Van Hoof wrote: > > 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 _______________________________________________ tracker-list > > mailing list tracker-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/tracker-list > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.20 (MingW32) > > iQEcBAEBAgAGBQJVAbIVAAoJEEP2NSGEz4aD1REH/0ohlPlKWDKxaU1F3Rqk6t0M > JVxosn+czIHj9jD6bz795FIjcWkGJldRZV9H4wN1US0vHvYOxL2HDeHNzX6xGQE3 > FOXgjJnqoAunLWo/65yHDYD54ge59Y+U93seC9IXhpPSoYX6eMDu0EQIp99GvZdv > RTPvoSMGtcNEdXF2QufCg9J122J3hBphjUQl1ohBUZL4Hlnxyqmpq4FxehOCD2Rz > oYxZnlTv7+Frr69qWZHU3W9KnkY+VRuIG9JC3ViNtBwYMl1xyNx0nlTASob3BWg9 > rJYgEe9GQztpwlPqIffnL5HZkTnUZFug/ZkSNyU5bcCRxRQYbYtbW+TnlxoRx4Q= > =Fp3E > -----END PGP SIGNATURE----- > _______________________________________________ > tracker-list mailing list > tracker-list@gnome.org > https://mail.gnome.org/mailman/listinfo/tracker-list >
_______________________________________________ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
