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

[Milan Crha <mcrha redhat com>]

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