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