On Fri, 2009-07-24 at 20:20 +0200, Patrick Ohly wrote:
> Hello!
> Let's pick up this discussion again. When we agree on the API changes,
> then I'll try to follow up with an implementation for the file backend.
> On Thu, 2009-01-08 at 13:48 +0100, Patrick Ohly wrote:
> > 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've come to the conclusion that overloading the old calls is not worth
> the trouble. Therefore I now suggest to add new variants of the call
> because...
> > 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.
> ... we need these new variants for the delete operations anyway.
> I have not looked at the calendar API yet. Let me know what you think
> about the attached patch for a new ebook API and I will continue with
> calendar next, before implementing anything.
Then changes made are reasonable. Nice api documentation! This can be
done in calendar also. For calendars we use sequence numbers for items
shared with people and last-modified in general.

> In this current incarnation the patch tries a bit to provide simple
> implementations of the new calls, but this isn't meant to be complete.
Would be better to get these api's committed after the branching is done
for 2.27.x. We will be merging the eds-addressbook dbus port this week
(for 2.27.x) and the calendar part for evolution 3.0. Will keep you
informed on the same.

- Chenthill.

Evolution-hackers mailing list

Reply via email to