On Di, 2011-03-22 at 09:34 +0100, Patrick Ohly wrote: > Hello Zoltan, > > I can't comment on the decision making process (that's above my grade > level) and don't want to (this is a technical mailing). > > On Di, 2011-03-22 at 08:02 +0000, [email protected] wrote: > > Option 2 from below would be the cheapest, fastest and least pain path but > > it's duplicating contacts to tracker. Option 3 would be optimal but > > difficult, > > option 1 could also work. Choose one, or suggest something else. Please > > finish > > the job you started :). > > Option 2 seems like a reasonable approach to me, if we can make it so > that the call history database is self-contained and merely mirrors the > subset of the contact data in read-only mode that is relevant for a > quick list of results, with more details fetched on demand from the main > contact database.
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. -- 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
