Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?

2011-05-17 Thread 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
various orders.

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,
without Evolution.

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
--  
patrick.o...@gmx.de
http://www.estamos.de/

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
  calls remove_instance().
- remove_instance() was extended to also work for the parent
  event.
- 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
--- a/calendar/backends/file/e-cal-backend-file.c
+++ b/calendar/backends/file/e-cal-backend-file.c
@@ -2629,47 +2629,94 @@ e_cal_backend_file_modify_object (ECalBackendSync *backend, EDataCal *cal, const
 	g_static_rec_mutex_unlock (priv-idle_save_rmutex);
 }
 
-static void
-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 must remain valid even if the object gets
+ * removed
+ * @ridNULL, , or non-empty string when manipulating a specific recurrence;
+ * also must remain valid
+ * @return modified object or NULL if it got removed
+ */
+static ECalBackendFileObject *
+remove_instance (ECalBackendFile *cbfile, ECalBackendFileObject *obj_data, const gchar *uid, const gchar *rid)
 {
 	gchar *hash_rid;
 	ECalComponent *comp;
 	struct icaltimetype current;
 
-	if (!rid || !*rid)
-		return;
+	/* only check for non-NULL below, empty string is detected here */
+	if (rid  !*rid)
+		rid = NULL;
 
-	if (g_hash_table_lookup_extended (obj_data-recurrences, rid, (gpointer *)hash_rid, (gpointer *)comp)) {
-		/* remove the component from our data */
+	if (rid) {
+		/* remove recurrence */
+		if (g_hash_table_lookup_extended (obj_data-recurrences, rid,
+		  (gpointer *)hash_rid, (gpointer *)comp)) {
+			/* remove the component from our data */
+			icalcomponent_remove_component (cbfile-priv-icalcomp,
+			e_cal_component_get_icalcomponent (comp));
+			cbfile-priv-comp = g_list_remove (cbfile-priv-comp, comp);
+			obj_data-recurrences_list = g_list_remove (obj_data-recurrences_list, comp);
+			g_hash_table_remove (obj_data-recurrences, rid);
+		} else {
+			/* not an error, only add EXDATE */
+		}
+		/* 

Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?

2011-05-16 Thread Milan Crha
On Thu, 2011-05-12 at 12:44 +0200, Patrick Ohly wrote:
 I found this in e-data-cal-view.c notify_remove():
 
 280   /* TODO: store ECalComponentId instead of just uid*/
 281   uid = g_strdup (id-uid);
 282   g_array_append_val (priv-removes, uid);
 
 In other words, removes always come without rid, even if the actual
 event that was removed was not the parent but a detached recurrence.
 ...
 It'll lead to a change of the D-Bus API. For master that shouldn't
 be a problem, but I also want this in MeeGo for KCal-EDS, based on
 2.32. I guess we have to bite the bullet and maintain a MeeGo version
 with a different API than regular 2.32.x.

Hi,
I noticed it too, recently (at the beginning of this week, actually).
I suggest to not change the D-Bus API, rather encode the string pair
into the string, like uid\nrid. I was planning to do so in the master
branch, but didn't do that yet.

 One more question about e_cal_backend_notify_object_removed(): it takes
 iCalendar 2.0 object strings as parameter in addition to the id. If both
 are set, it acts like object_updated. If the new object is NULL, it
 checks whether the old_object matches the view. Is that really
 necessary? There is a second check whether the ID is in the view in
 e_data_cal_view_notify_objects_removed():
 
 701   for (l = ids; l; l = l-next) {
 702   ECalComponentId *id = l-data;
 703   if (g_hash_table_lookup (priv-ids, id))
 704   notify_remove (view, id);
 705   }
 
 At least that is my understanding. So is it safe to pass only the ID and
 old_object = object = NULL?

You can pass both NULL if the old_object was completely removed. The
call if the object matches the view was kept there in time when the test
for !old_object was added. I do not recall exact circumstances, but I
think there was some rationale why it is so, though looking at it the
call of e_data_cal_view_object_matches() in
e_cal_backend_notify_object_removed() really seems unnecessary. Maybe it
was because of no expectations on the behaviour of
e_data_cal_view_notify_objects_removed_1().
Hope that helps a bit,
Milan

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?

2011-05-16 Thread Patrick Ohly
On Do, 2011-05-12 at 13:17 +0200, Milan Crha wrote:
 On Thu, 2011-05-12 at 12:44 +0200, Patrick Ohly wrote:
  I found this in e-data-cal-view.c notify_remove():
  
  280   /* TODO: store ECalComponentId instead of just uid*/
  281   uid = g_strdup (id-uid);
  282   g_array_append_val (priv-removes, uid);
  
  In other words, removes always come without rid, even if the actual
  event that was removed was not the parent but a detached recurrence.
  ...
  It'll lead to a change of the D-Bus API. For master that shouldn't
  be a problem, but I also want this in MeeGo for KCal-EDS, based on
  2.32. I guess we have to bite the bullet and maintain a MeeGo
 version
  with a different API than regular 2.32.x.
 
 Hi,
 I noticed it too, recently (at the beginning of this week, actually).
 I suggest to not change the D-Bus API, rather encode the string pair
 into the string, like uid\nrid. I was planning to do so in the
 master branch, but didn't do that yet. 

That's still a D-Bus API change: a libecal which receives a UID entry in
that format won't know what to do with it. But it'll be easier to
implement that way, so I'll give it a try first.

I'll do it as uid[\nrid] so that entries without an rid continue to
look exactly like the current ones.

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


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?

2011-05-13 Thread Ross Burton
On 12 May 2011 11:44, Patrick Ohly patrick.o...@gmx.de wrote:
 Can you perhaps comment? You wrote the TODO items below...
[snip]
 I can fix these TODOs. Any objections or concerns?

None whatsoever, those are embarrassingly leftin from the very early
porting where large chunks of code were copied from the contacts code
that just had an UID...

 It'll lead to a change of the D-Bus API. For master that shouldn't be
 a problem, but I also want this in MeeGo for KCal-EDS, based on 2.32. I
 guess we have to bite the bullet and maintain a MeeGo version with a
 different API than regular 2.32.x.

I've always said that the DBus interface isn't a stable API and
shouldn't be trusted to remain constant.  If nobody else documented
that the DBus interface is stable then we shouldn't worry too much.
As a DBus API designed to be used by anything other than
libebook/libecal it's pretty dire.

 One more question about e_cal_backend_notify_object_removed(): it takes
 iCalendar 2.0 object strings as parameter in addition to the id. If both
 are set, it acts like object_updated. If the new object is NULL, it
 checks whether the old_object matches the view. Is that really
 necessary? There is a second check whether the ID is in the view in
 e_data_cal_view_notify_objects_removed():

 701             for (l = ids; l; l = l-next) {
 702                     ECalComponentId *id = l-data;
 703                     if (g_hash_table_lookup (priv-ids, id))
 704                         notify_remove (view, id);
 705             }

 At least that is my understanding. So is it afe to pass only the ID and
 old_object = object = NULL?

The logic there is probably mostly identical to the original logic in
the ORBit port, and the calendar side isn't something I'm
knowledgeable in...

That said the view checking seems to have been to ensure that you
don't get remove events for items you've never had.  As to the
semantics, I'd say if they are not documented make them reasonable and
document them. :)

Ross
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?

2011-05-13 Thread Matthew Barnes
On Fri, 2011-05-13 at 12:48 +0100, Ross Burton wrote: 
 On 12 May 2011 11:44, Patrick Ohly patrick.o...@gmx.de wrote:
  It'll lead to a change of the D-Bus API. For master that shouldn't be
  a problem, but I also want this in MeeGo for KCal-EDS, based on 2.32. I
  guess we have to bite the bullet and maintain a MeeGo version with a
  different API than regular 2.32.x.
 
 I've always said that the DBus interface isn't a stable API and
 shouldn't be trusted to remain constant.  If nobody else documented
 that the DBus interface is stable then we shouldn't worry too much.
 As a DBus API designed to be used by anything other than
 libebook/libecal it's pretty dire.

It's fine to change the D-Bus API as needed, but remember to bump the
version number in the bus name.  I only recently added version numbers
after the whole 2.30 - 2.32 upgrade debacle, so we're still at:

   org.gnome.evolution.dataserver.AddressBook0
   org.gnome.evolution.dataserver.Calendar0

The bus names are defined in evolution-data-server/configure.ac.

This avoids the problem of users upgrading a client package like
Evolution while the older D-Bus services continue running.  If the D-Bus
interface changed, now suddenly the client can't talk to the services
correctly anymore.  That's what caused all the problems with local://
ESource URIs in 2.32.


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?

2011-05-13 Thread Patrick Ohly
On Fr, 2011-05-13 at 12:48 +0100, Ross Burton wrote:
 On 12 May 2011 11:44, Patrick Ohly patrick.o...@gmx.de wrote:
  Can you perhaps comment? You wrote the TODO items below...
 [snip]
  I can fix these TODOs. Any objections or concerns?
 
 None whatsoever, those are embarrassingly leftin from the very early
 porting where large chunks of code were copied from the contacts code
 that just had an UID...

Did the previous code transmit UID+RECURRENCE-ID? I am wondering why
Evolution manages to keep views properly in sync despite the lack of the
RECURRENCE-ID - and what'll happen when it starts receiving them.

I guess I'll find out...

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


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?

2011-05-13 Thread Ross Burton
On 13 May 2011 16:11, Patrick Ohly patrick.o...@gmx.de wrote:
 Did the previous code transmit UID+RECURRENCE-ID? I am wondering why
 Evolution manages to keep views properly in sync despite the lack of the
 RECURRENCE-ID - and what'll happen when it starts receiving them.

 I guess I'll find out...

I can't recall, sorry.  Time to get a checkout from before the DBus merge...

Ross
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?

2011-05-12 Thread Patrick Ohly
Hello Ross!

Can you perhaps comment? You wrote the TODO items below...

On Di, 2011-05-03 at 18:04 +0200, Patrick Ohly wrote:
 I also wonder about the objects-removed signal in ECalView. If there
 are two events, one with RRULE and one with RECURRENCE-RULE, and both
 get removed, should there be two entries in objects-removed?

I found this in e-data-cal-view.c notify_remove():

280 /* TODO: store ECalComponentId instead of just uid*/
281 uid = g_strdup (id-uid);
282 g_array_append_val (priv-removes, uid);

In other words, removes always come without rid, even if the actual
event that was removed was not the parent but a detached recurrence.

There's another, similar TODO in send_pending_removes():

192 /* TODO: send ECalComponentIds as a list of pairs */
193 e_gdbus_cal_view_emit_objects_removed (view-priv-gdbus_object,
(const gchar * const *) priv-removes-data);

And sure enough, the actual D-Bus API uses an array of strings instead
of an array of string pairs.

I can fix these TODOs. Any objections or concerns?

It'll lead to a change of the D-Bus API. For master that shouldn't be
a problem, but I also want this in MeeGo for KCal-EDS, based on 2.32. I
guess we have to bite the bullet and maintain a MeeGo version with a
different API than regular 2.32.x.

One more question about e_cal_backend_notify_object_removed(): it takes
iCalendar 2.0 object strings as parameter in addition to the id. If both
are set, it acts like object_updated. If the new object is NULL, it
checks whether the old_object matches the view. Is that really
necessary? There is a second check whether the ID is in the view in
e_data_cal_view_notify_objects_removed():

701 for (l = ids; l; l = l-next) {
702 ECalComponentId *id = l-data;
703 if (g_hash_table_lookup (priv-ids, id))
704 notify_remove (view, id);
705 }

At least that is my understanding. So is it safe to pass only the ID and
old_object = object = NULL?

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


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?

2011-05-11 Thread Patrick Ohly
On Di, 2011-05-10 at 10:23 +0200, Milan Crha wrote:
 On Wed, 2011-05-04 at 17:31 +0200, Patrick Ohly wrote:
  On Mi, 2011-05-04 at 09:41 +0200, Patrick Ohly wrote:
   On Mi, 2011-05-04 at 07:50 +0200, Milan Crha wrote:
I would expect that with CALOBJ_MOD_THIS it may remove only exact
component, for uid + NULL-rid the master object (which implies also all
generated instances) and keep all detached instances,
   
   Okay, then we agree on the desired semantic.
  
  I ran into another oddity: suppose there is a recurring event without
  exceptions and a detached recurrence gets added. The libecal API does
  not support undoing that operation.
  ...
 
   Hi,
 it sounds like you might find useful an addition of a reverse function
 for
 gboolean e_cal_client_get_object_sync (
  ECalClient *client,
  const gchar *uid, const gchar *rid,
  icalcomponent **icalcomp,
  GCancellable *cancellable, GError **error);
 which can return either one component, or a VCALENDAR component.
 
 I'm thinking of something like:
e_cal_client_replace_object (..., const gchar *uid,
  /* const */ icalcomponent *icalcomp, ...);
 Note it doesn't take the 'rid' parameter as the get_object function.

Yes, there might be cases where that is better than the current API. But
I see it as complementary to enhancing the existing, single-event
focused APIs.

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


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?

2011-05-10 Thread Milan Crha
On Wed, 2011-05-04 at 17:31 +0200, Patrick Ohly wrote:
 On Mi, 2011-05-04 at 09:41 +0200, Patrick Ohly wrote:
  On Mi, 2011-05-04 at 07:50 +0200, Milan Crha wrote:
   I would expect that with CALOBJ_MOD_THIS it may remove only exact
   component, for uid + NULL-rid the master object (which implies also all
   generated instances) and keep all detached instances,
  
  Okay, then we agree on the desired semantic.
 
 I ran into another oddity: suppose there is a recurring event without
 exceptions and a detached recurrence gets added. The libecal API does
 not support undoing that operation.
 ...

Hi,
it sounds like you might find useful an addition of a reverse function
for
gboolean e_cal_client_get_object_sync (
 ECalClient *client,
 const gchar *uid, const gchar *rid,
 icalcomponent **icalcomp,
 GCancellable *cancellable, GError **error);
which can return either one component, or a VCALENDAR component.

I'm thinking of something like:
   e_cal_client_replace_object (..., const gchar *uid,
 /* const */ icalcomponent *icalcomp, ...);
Note it doesn't take the 'rid' parameter as the get_object function.

Its meaning would be drop whatever you have stored for the component of
the given uid and use content of given icalcomp instead, which could be
either single component or a VCALENDAR with a list of detached
components. There might be some checking that the uid matches uids
stored in the icalcomp, but that's a minor thing.

Just an idea.
Bye,
Milan

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?

2011-05-04 Thread Patrick Ohly
On Mi, 2011-05-04 at 07:50 +0200, Milan Crha wrote:
 I would expect that with CALOBJ_MOD_THIS it may remove only exact
 component, for uid + NULL-rid the master object (which implies also all
 generated instances) and keep all detached instances,

Okay, then we agree on the desired semantic.

 though this
 operation doesn't seem to have much sense to me.

It's certainly not a common operation, but the API should allow it
nevertheless, because otherwise correct synchronization between a
database where such an operation took place (for whatever reason) and
EDS is hard.

  The problem is that
 each backend has its own implementation of such operation (also note
 that groupwise backend has no master object (it tells it in
 capabilities)) and for example file backend behaves with rid=NULL
 mod=CALOBJ_MOD_THIS the same like with mod=CALOBJ_MOD_ALL, thus it drops
 also detached instances.

If a backend doesn't support the semantic, then there's not much that
can be done. But the file backend should be able to to handle it,
therefore I consider it a bug that it removes all instances in this
case.

I'll look into fixing this.

  I also wonder about the objects-removed signal in ECalView. If there
  are two events, one with RRULE and one with RECURRENCE-RULE, and both
  get removed, should there be two entries in objects-removed?
 
 I've no idea on this. I'm sorry.

First things first ;-) Let me fix the removal, then look into this
problem here.

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


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?

2011-05-04 Thread Patrick Ohly
On Mi, 2011-05-04 at 09:41 +0200, Patrick Ohly wrote:
 On Mi, 2011-05-04 at 07:50 +0200, Milan Crha wrote:
  I would expect that with CALOBJ_MOD_THIS it may remove only exact
  component, for uid + NULL-rid the master object (which implies also all
  generated instances) and keep all detached instances,
 
 Okay, then we agree on the desired semantic.

I ran into another oddity: suppose there is a recurring event without
exceptions and a detached recurrence gets added. The libecal API does
not support undoing that operation.

e_cal_remove_object_with_mod(rid=datetime, CALOBJ_MOD_THIS) will
remove the recurrence but it will *also* add an EXDATE for that
recurrence. So the calendar is not in the same state as it was before
adding the detached recurrence.

This behavior may make sense for a UI (remove this recurrence implies
adding the EXDATE), but not for syncing.

May I add a CALOBJ_MOD_REALLY_REALLY_REMOVE_THIS_ONLY mode?

 If a backend doesn't support the semantic, then there's not much that
 can be done. But the file backend should be able to to handle it,
 therefore I consider it a bug that it removes all instances in this
 case.
 
 I'll look into fixing this.

I have a patch ready. Will continue to test and send when the rest also
passes my tests.

   I also wonder about the objects-removed signal in ECalView. If there
   are two events, one with RRULE and one with RECURRENCE-RULE, and both
   get removed, should there be two entries in objects-removed?
  
  I've no idea on this. I'm sorry.
 
 First things first ;-) Let me fix the removal, then look into this
 problem here.

ECalView is indeed odd. My initial understanding is that the file
backend will never send information about removed detached recurrences,
so rid is always empty.

What I get instead when removing a detached recurrence is a master
modified with EXDATE set. I suspect that the Evolution UI uses that to
remove the corresponding detached recurrence. Does anyone know whether
that is the case?

If I introduce the CALOBJ_MOD_REALLY_REALLY_REMOVE_THIS_ONLY, then
EXDATE won't be set and a real object-removed with rid set will be
needed.

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


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?

2011-05-03 Thread Milan Crha
On Tue, 2011-05-03 at 18:04 +0200, Patrick Ohly wrote:
 I was hoping to avoid this with more recent EDS, the local file backend
 and simply calling e_cal_remove_object_with_mod() regardless whether it
 has an rid or not. But it turns out that
 e_cal_remove_object_with_mod(rid=) simply calls the removeObject D-Bus
 method with an empty string for the rid, just like e_cal_remove_object()
 does, and thus all events sharing the same UID get deleted.
 
 rid=NULL doesn't make any difference.
 
 What is the intended semantic of e_cal_remove_object_with_mod()? If rid
 empty or NULL, then remove only parent?

Hi,
using NULL or an empty string for 'rid' is equivalent. It's quite hard
to pass NULL strings over DBus, so NULL is changed to an empty string
anyway, and on the server-side it is changed to NULL, though each
backend checks for NULL or empty string too.

I would expect that with CALOBJ_MOD_THIS it may remove only exact
component, for uid + NULL-rid the master object (which implies also all
generated instances) and keep all detached instances, though this
operation doesn't seem to have much sense to me. The problem is that
each backend has its own implementation of such operation (also note
that groupwise backend has no master object (it tells it in
capabilities)) and for example file backend behaves with rid=NULL
mod=CALOBJ_MOD_THIS the same like with mod=CALOBJ_MOD_ALL, thus it drops
also detached instances.

In other words, the 'mod' may make the difference, from my point of
view.

 I also wonder about the objects-removed signal in ECalView. If there
 are two events, one with RRULE and one with RECURRENCE-RULE, and both
 get removed, should there be two entries in objects-removed?

I've no idea on this. I'm sorry.
Bye,
Milan

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers