Re: [Tracker] Tracker and Contacts

[Adrien Bustany <abustany gnome org>]

Le Sun, 23 Jan 2011 17:01:59 +0100,
Philip Van Hoof <spam pvanhoof be> a écrit :

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

Definitely, I won't be there this year though :/

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

To me, transient only means "not meant to be persisted", so that can be
optimized how you want it in Tracker.

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

Good point, I had skipped this use case. But then, if we have presence
into tracker, libfolks would be a G equivalent to qtcontacts-tracker &
contactsd?

> 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