Re: [Phpgroupware-developers] addbook conduit logic

[Brian Johnson]

Oh I get it

I think I might leave that for a future feature - after I get the main syncing
going.

One of the problems I'm trying to find a solution to is that I might not know 
all
of the field names because of the way addbook allows additional contact info
(currently called additional contact categories)



Jason Wies (address@hidden) wrote*:
>
>On Sun, Jul 21, 2002 at 03:19:36AM +0000, Brian Johnson wrote:
>> >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?
>
>I don't see why you need to decide which is more likely.  In the palm_addbook2
table, there is a separate record for each field that has changed, and these
records are not dependant on which invididual record the change came from on the
Palm.  Example:
>
>Individual 1:
> Address
> Phone
>Individual 2:
> Zip code
>Individual 3:
> Phone
>
>When reading and comparing records for Individual 1 and Individual 2, three
records would be created in the palm_addbook2 table, something like:
>
>+------------------+------------------+---------------------+---------+-----------------+
>| palm_addbook2_id | phpgw_org_rec_id | datetime            | field   | md5sum
|
>+------------------+------------------+---------------------+---------+-----------------+
>|                1 |               23 | 2002-07-20 22:12:17 | address |
d41d8cd98f00b20 |
>|                2 |               23 | 2002-07-20 10:34:54 | phone   |
d800998ecf8427e |
>|                3 |               23 | 2002-07-20 12:12:43 | zip     |
f00b204e98003ec |
>+------------------+------------------+---------------------+---------+-----------------+
>
>When the conflicting record for Individual 3 is read and compared, a decision
must be made whether to keep the phone record from Individual 1 or replace it 
with
the one from Individual 3.  I can think of all kinds of interesting ways of
deciding which to keep (datestamps, number of records containing the two 
different
values, number of fields changed for each Individual (the more fields changed, 
the
more reliable the information)) and so on and so forth.  However, without a
massive amount of theoretical work on the issue, you're never going to be able 
to
correctly decide which to keep in all cases, so it is best to ask the user which
is the correct value and then sync with that.
>
>>
>> >
>> >> 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?
>
>No, MD5 sum is just a cleaner way of providing a unique value (but see below).
>
>> 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
>
>Same argument, same answer.  You may be able to take more liberty with 
>automated
decision making here if you know for sure the last sync was interrupted.  
However,
it's still best to prompt the user and have them decide which value to keep.  
And
on that note, I guess I have to take back storing the MD5 sum instead of storing
the actual value, because when you present the user which two choices, the MD5 
sum
won't help them decide which to keep, and it also won't help restore the value.
So scratch the MD5 sum in favor of the actual value, it won't work for 
interrupted
syncs.
>
>As for the actual interface, I think it would be best to sync everything that
doesn't have conflicts, and then present the user with an "Oops! Conflicts were
found!  Please choose the correct value from the choices below." screen, and 
then
update the palm_addbook2 table with their choices and sync again (hopefully 
using
the same sync routine, just with updated values).
>
>Jason
>
>_______________________________________________
>Phpgroupware-developers mailing list
>address@hidden
>http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>