On Tue, 2009-07-28 at 13:05 +0530, Chenthill wrote:
> On Fri, 2009-07-24 at 20:20 +0200, Patrick Ohly wrote:
> > 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
I'm not sure what you mean with "items shared with people". Care to
explain?
> and last-modified in general.
SyncEvolution is based on LAST-MODIFIED since 0.8.x, as mentioned on
this list before.
Attached is my current patch set, with one typo fix in the ebook part
and the ecal API also extended. Less functions need to be patched
because there is no async API.
> > 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.
Implementing the new API would require changing the libecal/ebook<->EDS
communication. Is that something that has to be done twice, once for the
old communication mechanism and once for D-Bus? Will there be a
configure switch to select between one or the other?
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
>From c7985fca473926b1058dc4859fb77f7b3dacb19b Mon Sep 17 00:00:00 2001
From: Patrick Ohly
Date: Fri, 17 Jul 2009 16:27:29 +0200
Subject: [PATCH 1/3] documentation fix
e_book_remove_contact_by_id() does not exist, probably
e_book_remove_contact() was meant.
---
addressbook/libebook/e-book.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/addressbook/libebook/e-book.c b/addressbook/libebook/e-book.c
index e9b3b01..fefe4fa 100644
--- a/addressbook/libebook/e-book.c
+++ b/addressbook/libebook/e-book.c
@@ -1688,7 +1688,7 @@ e_book_remove_contact (EBook *book,
* @error: a #GError to set on failure
*
* Removes the contacts with ids from the list @ids from @book. This is
- * always more efficient than calling e_book_remove_contact_by_id if you
+ * always more efficient than calling e_book_remove_contact() if you
* have more than one id to remove, as some backends can implement it
* as a batch request.
*
@@ -1769,7 +1769,7 @@ e_book_async_remove_contact_by_id (EBook *book,
* @closure: data to pass to callback function
*
* Removes the contacts with ids from the list @ids from @book. This is
- * always more efficient than calling e_book_remove_contact_by_id() if you
+ * always more efficient than calling e_book_remove_contact() if you
* have more than one id to remove, as some backends can implement it
* as a batch request.
*
--
1.6.2
>From 78a7b1bbe267b3171d7614946589b6b386c0c242 Mon Sep 17 00:00:00 2001
From: Patrick Ohly
Date: Fri, 24 Jul 2009 20:08:01 +0200
Subject: [PATCH 2/3] ebook atomic updates and deletes: check and return revision
Same API change as for ecal, using REV instead of LAST-MODIFIED.
The current API suffers from multiple race conditions: when
overwriting a contact, another client might have already made
an update that gets overwritten by older data. Removing a
contact is also affected => added an API extension that
allows backends a) to detect that clients want the more
careful data modifications and b) provides enough information
to do the checking based on the revision string in the backend
(EBOOK_STATIC_CAPABILITY_ATOMIC_MODIFICATIONS).
Software that does change tracking based on the revision string
(like SyncEvolution) needs to know which revision string was
assigned to an updated or added contact. Currently it must do
the operation, then ask for the whole contact. There is a small
window for a race condition here, but more important, this
requires another round-trip and transmit too much information.
With EBOOK_STATIC_CAPABILITY_RETURN_REV the client can be sure
to get the necessary information right away.
---
addressbook/libebook/e-book-types.h | 12 ++
addressbook/libebook/e-book.c | 268 +-
addressbook/libebook/e-book.h |6 +
3 files changed, 278 insertions(+), 8 deletions(-)
diff --git a/addressbook/libebook/e-book-types.h b/addressbook/libebook/e-book-types.h
index 00a814e..2dadf27 100644
--- a/addressbook/libebook/e-book-types.h
+++ b/addressbook/libebook/e-book-types.h
@@ -64,11 +64,23 @@ typedef enum {
E_BOOK_CHANGE_CARD_MODIFIED
} EBookChangeType;
+typedef enum {
+ E_BOOK_UNDEFINED_REVISION_HANDLING = 0,
+ E_BOOK_IGNORE_REVISION = 1<<0,
+ E_BOOK_CHECK_REVISION = 1<<1,
+ E_BOOK_SET_REVISION = 1<<2
+} EBookRevisionHandlingFlags;
+
typedef struct {
EBookChangeType change_type;
EContact*contact;
