GNOME.org
 

Re: [Tracker] Plan of action - Was: Urgent - Suggestions for new major functionality - Project

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/03/2015 17:22, Ivan Frade wrote:

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.


I think Tracker is the wrong project for that goal. The right project
for that goal is Nepomuk. We just facilitate Nepomuk with a SPARQL
endpoint and a metadata file extractor and filesystem miner.

Tracker's filesystem miner will use that Nepomuk as ontology and
create an application-group that on most desktops will be the central
storage point for many things.

But I see no reason why libtracker-sparql and tracker-store can't be
utilized for other purposes, too. Technically they sure can. The only
reason why it's not, is because of how things are set up by default.

ps. You can try pointing tracker-store at a different ontology and
change the filename of meta.db to something else, en then do SPARQL
with libtracker-sparql and use that other ontology. It'll work fine.


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.


Full graphs with the current sqlite denormalized SQL-schema
architecture of Tracker is very difficult and not likely to happen.

Full graph support would indeed be a different way to support the same
use-cases that I have in mind for allowing multiple application groups
and multiple simultaneous ontologies.

I lean more towards the embedded use-cases for Tracker's
libtracker-sparql and tracker-store. There full graph support is
overkill, and I believe that just making it possible to have multiple
ontologies and groups of applications flocking to a tracker-store
instance is sufficient (with Tracker's filesystem miner and the
gnome-miners probably going to be the ones defining the most used such
application group).

Kind regards,

Philip



On Thu, Mar 12, 2015 at 8:34 AM, Philip Van Hoof
<philip codeminded be> wrote:

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




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

iQEcBAEBAgAGBQJVAcbCAAoJEEP2NSGEz4aDDCkIAIgvqn7K6x2TVuMZSx5FVhY1
oD89w7Q416oeYBgIA76witcJNosH0xJ4ZU4cCjOSQyCSyZjMv4Vh9bo5BIl17hHK
fxzc1iVk96SZlARzax+vnDQEBOgXUy8x44qhWkCI8508iLYqkVMLutHHKFp/sPod
WGzrz4JX1JJShc+o2QZxyeB3ee/Sf4DbPLNFkBaOF3LvIDf5gYJVy8+W277A5wnz
V6rjilJJ6slH08q9bZGgU128EGZmw2l/qh8fg+df6n3gtsJXwYIvm6H854QUqeGJ
/SiYcAh5mOtxu28ZNztgluKTdkjrn2m0QBLXLLkzDEd+MxPx+EzUbA3N6TZZV5g=
=syqu
-----END PGP SIGNATURE-----
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]