On Tue, 22 Mar 2011 09:34:40 +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.
Whether that database is Tracker remains to be seen.
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.
You're right, currently that "matching" length is set system wide. That
would be however quite easy to fix (using libphonenumber for matching
wouldn't be hard either), it's actually not the jobs of Tracker but of
the apps to fill that "cached lookup value". Patching commhistory and
qtcontacts-tracker to do the lookup not using a fixed length but
whatever value would be very easy. We never had a bug report about it
though, as far as I remember, and it does not look like a fundamental
architecture issue.
Cheers
Adrien
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
