Jppy: AddressDB support in python-jppy

David A. Desrosiers hacker at gnu-designs.com
Tue Feb 13 14:03:30 GMT 2007


On Tue, 2007-02-13 at 13:43 +0000, Nicholas Piper wrote:
> > At best, any conduit that we write now, that uses AddressDB, should
                                           ^^^^^^^^^
> > write those records to ContactsDb-PAdd and delete AddressDB.pdb from
> > the device after a clean sync to ensure that those records get put
> > in the right place. 

> Do you mean 'that uses ContactsDB-PAdd' ? Anything that uses AddressDB
> probably only does so because it is old code, *or* using a device
> which is older. 

No, I meant any conduit that uses AddressDB _in current conduits_, needs
to be rewritten to use ContactsDb-PAdd instead, and here's why: 

I see a (growing) number of people who continue to use applications that
request the CreatorID of 'addr' from their OS5 device; a device which
natively supports Contacts, and does not natively support Address Book. 

When an application on the Palm (or a conduit) requests 'addr', the
Contacts application will create a "view" (in the SQL sense) of the
ContactsDb-PAdd data suitable for backward compatibility with that
"legacy" application. 

Its _supposed_ to incorporate any changes made to the AddressDB "view"
data back into ContactsDb-PAdd upon close/exit, but I've seen and heard
reported many times that it does not (conduits crashing, Palm resetting,
communication disruption or timeout or any other condition that can
cause the two to become confused). 

What I'm suggesting, is that on any OS5 device that supports Contacts
_and_ has applications that request the CreatorID 'addr' (this means ANY
device where ContactsDb-PAdd _and_ AddressDB are both present), we
should take what is in AddressDB, compare it with what is in
ContactsDb-PAdd, sync it to Contacts, and _delete_ AddressDB from the
device.

The next time an app or conduit requests 'addr' again, they'll get the
"clean" data that will be populated by Contacts. Think of it like
cleaning up a lockfile after an application crash... same sort of
theory. 


-- 
David A. Desrosiers
desrod at gnu-designs.com
Skype username: setuid
http://gnu-designs.com
”The palest ink is better than the most retentive memory.”
                                   - Old Chinese Proverb





More information about the Jppy mailing list