On Di, 2011-03-22 at 15:40 +0000, Adrien Bustany wrote: > On Tue, 22 Mar 2011 13:15:48 +0100, Patrick Ohly wrote: > > On Di, 2011-03-22 at 09:34 +0100, Patrick Ohly wrote: > > One more thought on this. Consider that a call was recorded at a time > > when there was a corresponding contact. Later the address book gets > > changed such that there is no match anymore - perhaps the contact was > > removed to clean up the address book, perhaps because his or her > > phone number changed. > > > > I would find it convenient if the call history gave me more than just > > the old phone number in such a case. Ultimately this is a question to > > the UX designers. > > > > My point here is that the caching scheme proposed above would support > > such a use case, whereas creating the match at the time of the query > > based on the then current data (as it is presumably done in > > Tracker/libcommhistory) doesn't. > > You just degrade the contact from a nco:PersonContact to a nco:Contact > in Tracker at delete time if it's linked to an existing call event.
Interesting approach... but how would that tie into deleting a contact via QtContacts? That's the API that will be used, not low-level Tracker manipulations. > What amuses me is that we started from a global architecture discussion > (are we going to make a house in wood or concrete), and we're right now > discussing the color of the handle of the window in the basement ;) But > details do matter too... Of course they do. It's part of verifying that architecture decisions do not run afoul of some constraints. We know that a house can be build from wood and concrete, because both has been done before. But can a plane be built from concrete? And no, I am not saying that either EDS or Tracker are the concrete in this example ;-) -- 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 http://wiki.meego.com/Mailing_list_guidelines
