Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?
- From: Patrick Ohly <patrick ohly gmx de>
- To: Evolution Hackers <evolution-hackers gnome org>
- Subject: Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?
- Date: Wed, 04 May 2011 09:41:13 +0200
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 Ohly gmx de
http://www.estamos.de/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]