Re: [Tracker] Tracker and Contacts

[Philip Van Hoof <spam pvanhoof be>]

On Sat, 2011-01-22 at 11:28 +0200, Adrien Bustany wrote:
> Le Thu, 20 Jan 2011 15:53:03 +0200,
> Ivan Frade <ivan frade gmail com> a Ãcrit :
>
> > Hi!
> >
> >  No, nobody is working on it :) It would be excellent. I took a look
> > into libfolks some time ago, and i think it could be done in two
> > steps:
>
> Well, I know at least one project using the contact ontology quite
> heavily: http://gitorious.org/qtcontacts-tracker/qtcontacts-tracker ;)
> So the ontologies are used and maintained. Then of course this is not
> GLib code, but it gives a good example of how to use nco to read
> contacts (and it would actually make sense for libfolks to follow the
> same conventions).
>
> > 1. Make a backend for libfolks that READs the contacts from tracker
> > (libfolks will save the results or merging contacts in its own .ini
> > file)
> >
> > 2. Make tracker the main backed of libfolks replacing that .ini file.
> > That would be awesome!
>
> It's still not very clear though if storing things like contact
> presence in Tracker is the best thing to do...

It would be interesting for the Tracker project if qtcontacts-tracker
and libfolks / Telepathy teams would some day sit together with us (the
entire Tracker team will for example be at FOSDEM) to discuss use-cases
and metadata needs.

> Especially since support for transient properties in Tracker proved
> to be not very conclusive :/

It would for example be good for us to know what kind of support for
transient properties you need from Tracker; how they should work. How
you people see it.

When it comes to typical transient properties for contacts and IM,
there's a thin line between being a metadata provider and turning into
an IPC abstraction, system or layer on top of D-Bus. We very much want
to focus on the former and avoid becoming the latter.

An example: using Tracker's class signals to replace file monitoring is
something that we don't recommend at all.

But nonetheless should we as teams working on these components that
ought to exchange and cooperate on (meta)data and sometimes functions /
actions make sure that we don't duplicate functionality, that we enable
use-cases, ease development, ease interopability, etc.

> So I'd say it probably makes sense to get the presence etc. directly
> from telepathy, or wherever it comes from, and do the merging "live"
> without passing by Tracker (which is actually one of the usecases of
> libfolks if I'm right?).

That probably makes sense. But when you need to involve the presence of
a contact in a query, Tracker probably needs the presence data too.

That however doesn't mean that applications should be recommended to use
Tracker's class-signal feature to update themselves about the presence
of a contact. Just that they might have to use it when the presence of a
contact is involved in the WHERE (the selection) of a query.

 SELECT nco:fullname (?c) { ?c a nco:IMContact ;
  ncal:birthday '$today' ;
  nco:imContactPresence nco:presence-status-available . }

The reason why we don't do much special for transient properties right
now is because due to libtracker-sparql's direct-access mode we can't
use SQLite's TEMPORARY tables. We tried with making a new .db file
on /dev/shm and then ATTACHing the .db file to meta.db's connection, but
that slowed down access to the transient data to the point of it being
much slower than just enduring the I/O on disk. We don't have much
transient properties anyway, so the little bit of extra I/O isn't
something that we are very worried about.

We do have a branch that removes the journaling of properties that are
annotated as transient. This branch has not been applied to master yet.
The performance improvement is negligible but at least the journal file
doesn't needlessly grow when transient properties change. We right now
also don't unset transient properties at restart, or at least isn't this
well tested anymore.


Cheers,

Philip


-- 


Philip Van Hoof
freelance software developer
Codeminded BVBA - http://codeminded.be