Hi Patrick, > From: Patrick Ohly [mailto:[email protected]], sent on 22 March, 2011 > 10:35 > 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.
Yes, and same for messaging (IM+SMS). This assumes the storage for IM + SMS + call history is still tracker. Strictly speaking, the requirement is just that contacts and the above should be stored in the same DB, whatever it is. Just out of curiosity, what would prevent support in EDS for IM+SMS+callhistory? Not that I would suggest it :). About shared models and caching (and then supporting heterogenous data sources) we are doing some prototyping now, I hope to share more on the MeeGo conference, but this won't work very soon, so it's out of question for now. > In my understanding, matching phone numbers in Tracker is based on a > fixed number of digits at the end of the phone number. The Wiki already > documents that this is only configurable on a system-wide basis, so if > my contacts are from China, the US and Europe (which in fact they are), > then the system settings might be wrong for some contacts (from > http://wiki.meego.com/Architecture/Documentation/PIM/Contacts_Engine#User_Data.2C_Configurability > ) > . > > I also heard that some US numbers have additional digits at the end > which also break the current matching. Sorry, I never saw a specific > example, otherwise I would provide it. > > To me that suggests that a matching between an address book and call > events is a fairly complex process which needs to be: > 1. done by custom software written specifically for this problem > domain (as in http://code.google.com/p/libphonenumber/), > 2. calculated as the data changes, > 3. cached to speed up the actual displaying. Valid points, we should improve on this with finer grained rules. Adding Andrea. Regards, Zoltan
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
