Re: [Phpgroupware-developers] addbook conduit logic

[Jason Wies]

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