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 -- [email protected] http://www.estamos.de/ _______________________________________________ Evolution-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-hackers
