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

[Ross Burton <ross burtonini com>]

On 12 May 2011 11:44, Patrick Ohly <patrick ohly 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