On Fri, 2010-06-25 at 08:01 +0100, Thiago Macieira wrote: > Em Sexta-feira 25. Junho 2010, às 08.48.34, Patrick Ohly escreveu: > > I have one conceptual question about QtContacts and Tracker. QtContacts > > is the high-level API that applications are meant to use. It abstracts > > away from the underlying storage mechanism, which happens to be Tracker > > when using the qtcontacts-tracker backend. > > > > The goal of using Tracker is that the data can be reused in other > > contexts, like direct SPARQL queries or other apps resp. APIs (like the > > future QtCalendar) - right? But how does that work in practice? > > > > When finding a contact in Tracker, it would be necessary to open it in > > QtContacts. Likewise, when creating a contact in QtContacts, some way of > > referencing it in Tracker is needed. Is there an implicit guarantee that > > the QContactId has a certain relationship with Tracker? > > I doubt that the Contacts API will give you that guarantee because it's > supposed to be backend-agnostic. It could be gathering data from multiple > backends and none of them might be Tracker.
That's indeed the point of my email: how can an app which uses QtContacts take advantage of Tracker? It seems that is not part of the design, which implies that apps trying to take advantage of Tracker are forced to ignore QtContacts. But that doesn't quite sound right to me, because QtContacts is a much more friendly API to store/retrieve contacts. It was mentioned on IRC that the QContactsID is probably stored in Tracker, which would provide the necessary link between the two layers for apps which know which backend they use (which *is* part of the QtContacts API, after all). It would be good to make this link official as part of the qtcontacts-tracker backend documentation. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
