Re: [Evolution-hackers] concurrent modifications of items in GUI and EDS database

[Patrick Ohly <patrick ohly gmx de>]

Hello Suman!

I forgot to ask: do you agree in general with the plan to do atomic
updates via e_book_commit_contact() and e_cal_modify_object() by
defining the semantic as suggested?

I also need to extend the proposal: removing an item has similar race
conditions (sync starts, user updates item, sync removes item). The
current APIs for removing items make it harder to pass in the expected
REV resp. LAST-MODIFIED. The only API call that could do it without
changing its prototype is e_book_async_remove_contact(EContact
*contact). e_book_remove_contact(), e_cal_remove_object(),
e_cal_remove_object_with_mod() all just take ID strings.

When e_cal_remove*() refers to multiple VEVENTs it might also be
difficult to specify the expected LAST-MODIFIED of each VEVENT. I don't
have a good solution for the remove case. New API calls?

e_cal_modify_object() has the same problem with multiple VEVENTs, but
this can be solved: for CALOBJ_MOD_THIS[ANDPRIOR|FUTURE], the
LAST-MODIFIED property of the referenced VEVENT is to be compared. For
CALOBJ_MOD_ALL the main event is checked.

-- 
Bye, Patrick Ohly
--  
Patrick Ohly gmx de
http://www.estamos.de/