phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Phpgroupware-developers] addbook conduit logic


From: Brian Johnson
Subject: Re: [Phpgroupware-developers] addbook conduit logic
Date: Sun, 21 Jul 2002 03:19:36 +0000

>You should also store the name of the field that changed, ie. address or 
>phone, so
that changes to two different fields of an organization's info on two different
individuals on the Palm could both by synced.  You only run into trouble when, 
say,
the address field for the organization is changed in two individual records.
Changing the address in one and the phone number in another shouldn't cause a
problem.

Ahh, but what if more than one organization field is changed with that first
individual (say address and phone - it eouldn't happen in my area, but in 
Toronto,
Ontario, Canada a move across the street could change suburb and area code, so 
new
phone number is needed)?  As a user, what are the chances that more than one 
field
would be changed vs what are the chances that if you are changing the org info, 
you
would chnage some of it on one individual's record and some of it on another
individual's record?

No seriously, what is better?


>
>> One potential problem with this is that
>> an interupted sync would prevent the organization's info from being changed
>> during the next sync and any changes not transferred before th interuption
>> would be lost
>
>It might be worth storing the MD5 sum of the field's value along with the field
name in the palm_addbook2 table.  This way you can recover from an interrupted 
sync
by comparing the previously stored value with the value coming from the Palm now
(although maybe just comparing date entered would be enough?).

Does the MD5 provide any better info than the content of the field itself?

Similar argument as above, what if more than one field is changed.  This looks 
like
it's leading to needing a second copy of all information.  The regular process 
is
to make comparison's and move changed info from phpgw to the Palm database file,
sync the Palm to the database file, and then make another comparison from the 
Palm
database file to phpgw and moved changed info back to phpgw (this last step 
could
occur after the Palm PDA is removed).

I guess the only risk of lost data applies even if the sync isn't interupted, 
it is
if the phpgw record for that contact is modified AND the Palm record is 
modified,
then the Palm copy overwrites the server copy.  I don't think there is way 
around
this one - and I don't know if it's really a big problem




reply via email to

[Prev in Thread] Current Thread [Next in Thread]