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

[Milan Crha <mcrha redhat com>]

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