[BitPim-devel] Proposed patch to phonebook.py

[Andrew Zitnay]

I'm still chugging along on phonebook support for my phone (LG VI-125), and
I'm almost done, but I wanted to run a patch for phonebook.py by you guys...
I was running into a problem with speed dials, where if there was one in the
BitPim database for a particular phone number, but not in the phone itself,
and I tried to update the BitPim database with the contents of the phone,
the speed dial wouldn't get removed from the BitPim database. I traced the
problem to phonebook.py, and the attached patch (phonebook.py.diff) fixes
the problem for me.

Please take this patch with a grain of salt; you guys have been working with
BitPim a lot longer than I have, so you're in a better position to know
whether or not this patch will screw up anything for any other model phone.
Let me know if it makes sense to do it my way, or if I'm misunderstanding
something.

Drew

[Roger Binns]

update the BitPim database with the contents of the phone, the speed
dial wouldn't get removed from the BitPim database. 

That is intentional. The phones store a crippled limited subset of
information. It was a deliberate choice to consider the existing
information in the BitPim database to be more authoritative than what
is coming off the phone.

This is definitely the right thing to do most of the time. For example
if the phone says someone's name is 'Long John Smi' and the database
says it is 'Long John Smith' then the database is right. Similarly the
phones have more limits on how many numbers, emails, urls etc they can
store and the length of them.

In the case of the speed dial we are unable to tell the difference
between the user intentionally not having a speed dial for an entry
(despite having one in the database) or because they haven't done them
on the phone and the entries should have a speed dial as the database
indicates.

The only solution to this is true synchronization. With true
synchronization you store what you sent the device last time and what
it has now. Any changes indicate a deliberate edit by the user. You
have to take into account how information gets mangled when you send it
(truncated or limited in other ways) and also timestamp when the
changes were likely made by the user since they can have multiple
devices and do synchronization and changes in any order order.

The current BitPim sync is the right thing (tm) for the very first sync
when you have no history.

Roger