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

Reply via email to