You are the calendar maintainer, right? Do you have some time to review
these patches? On this occasion let me add some further explanation of
the motivation for this patch series.
Traditionally, libecal has implemented parts of the semantic typically
associated with a UI: for example, it implements ensure that a
recurring event does not occur at this point in time, no matter what it
takes to achieve that. I consider this a high-level API.
The low-level API would be remove/add/modify this VEVENT. The libecal
API *looks* like it supports that and according to our previous
discussion is meant to (see the comments about
e_cal_remove_object_with_mod()), but the actual implementation differs.
This is a problem for sync operations, where that semantic is
implemented elsewhere and the calendar storage has to mirror the
operations done there (CalDAV/SyncML server in SyncEvolution; KCal in
the MeeGo architecture).
Therefore this patch series adds the missing operations. This is done so
that the file backend can replace other local storages that EDS is being
compared against. I understand that the vision of EDS goes beyond just
being a local storage, but that's irrelevant in the context of such
Bye, Patrick Ohly
On Mo, 2011-05-16 at 18:06 +0200, Patrick Ohly wrote:
I'll do it as uid[\nrid] so that entries without an rid continue to
look exactly like the current ones.
Looks good. I ran my KCal-EDS test program which adds, modifies and
removes events, including parent and child (= detached recurrence) in
I am now seeing all ECalView signals that I expect and need.
I also ran Evolution in parallel to the test and saw it react to all
signals, but not quite as I would have liked.
Evolution seems to interpret uid + empty rid as all recurrences
removed, which IMHO is wrong. It should mean parent removed, because
otherwise there is no way of expressing that change.
For child removed, parent not updated (= no EXDATE added) I would
expect Evolution to show the original, unmodified recurrence again.
Instead it only removes the recurrence (as if EXDATE had been added).
I consider this an Evolution bug which can and should be fixed
separately. Please understand that it is currently lower priority for
me, my main goal has to be to get EDS working as intended in EKCal-EDS,
Please have a look at the attached patch series. They were tested with
the gnome-2-32 branch. Except for the very last one, all apply to
master. Does this look okay? May I submit to master (after fixing
the last patch), gnome-3-0 and gnome-2-32?
Bye, Patrick Ohly
From 2e128c63a4a9dd64a3a327262498deb869a119f7 Mon Sep 17 00:00:00 2001
From: Patrick Ohly patrick.o...@intel.com
Date: Wed, 11 May 2011 16:59:51 +0200
Subject: [PATCH 1/8] calendar file backend: support removing parent event with CALOBJ_MOD_THIS
It was possible to create a meeting series with just a detached event
(RECURRENCE-ID set) by importing a meeting invitation for that single
recurrence. It was not possible to arrive at that same state after
adding the parent event (the one with the RRULE) because
e_cal_remove_object_with_mod() removed all instances for
CALOBJ_MOD_THIS and empty rid.
This contradicts the intended semantic of e_cal_remove_object_with_mod():
By using a combination of the @uid, @rid and @mod
arguments, you can remove specific instances. If what you want
is to remove all instances, use e_cal_remove_object instead.
This patch implements the desired semantic:
- e_cal_backend_file_remove_object(CALOBJ_MOD_THIS) now always
- remove_instance() was extended to also work for the parent
- That call removes the complete object if nothing is left
after removing the instance. This case must be handled by
the caller. The return value is the original object (if
it still exists) and NULL if not.
- Because the uid pointer into the object may become invalid
as part of the removal, a more permanent pointer has to
be provided by the caller.
calendar/backends/file/e-cal-backend-file.c | 134 ++-
1 files changed, 88 insertions(+), 46 deletions(-)
diff --git a/calendar/backends/file/e-cal-backend-file.c b/calendar/backends/file/e-cal-backend-file.c
index 33bab50..7a8c450 100644
@@ -2629,47 +2629,94 @@ e_cal_backend_file_modify_object (ECalBackendSync *backend, EDataCal *cal, const
-remove_instance (ECalBackendFile *cbfile, ECalBackendFileObject *obj_data, const gchar *rid)
+ * Remove one and only one instance. The object may be empty
+ * afterwards, in which case it will be removed completely.
+ * @uidpointer to UID which