Le Sun, 23 Jan 2011 17:01:59 +0100, Philip Van Hoof <s...@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.fr...@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 > > _______________________________________________ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
