GNOME Bugzilla – Bug 651970
ecal item semantic
Last modified: 2011-08-22 13:47:04 UTC
Traditionally, libecal has implemented parts of the semantic typically associated with a UI: for example, it implements "ensure that a recurring event does not occur at this point in time, no matter what it takes to achieve that". I consider this a high-level API. The low-level API would be "remove/add/modify this VEVENT". The libecal API *looks* like it supports that and according to our previous discussion is meant to (see the comments about e_cal_remove_object_with_mod()), but the actual implementation differs. This is a problem for sync operations, where that semantic is implemented elsewhere and the calendar storage has to mirror the operations done there (CalDAV/SyncML server in SyncEvolution; KCal in the MeeGo architecture). Therefore this patch series adds the missing operations. Please have a look at the attached patch series. They were tested with the gnome-2-32 branch. Except for the very last one, all apply to "master". Does this look okay? May I submit to "master" (after fixing the last patch), gnome-3-0 and gnome-2-32?
Created attachment 189291 [details] [review] calendar file backend: support removing parent event with CALOBJ_MOD_THIS
Created attachment 189292 [details] [review] libecal: added CALOBJ_MOD_ONLY_THIS
Created attachment 189293 [details] [review] catch invalid CalObjModType values
Created attachment 189294 [details] [review] calendar file backend: white list check for supported CalObjModType
Created attachment 189295 [details] [review] calendar file backend: removal notification for detached recurrence, part 1
Created attachment 189296 [details] [review] calendar file backend: removal notification for detached recurrence, part 2
Created attachment 189297 [details] [review] calendar file backend: support remove with CALOBJ_MOD_ONLY_THIS
Created attachment 189298 [details] [review] calendar: include rid in "objects-removed" ECalView signal Needs to be reworked to apply to master. Currently only applies to gnome-2-32 branch.
Review of attachment 189291 [details] [review]: Patch looks good. Please commit it to master and stable branches (gnome-3-0 and gnome-2-32 if needed).
Review of attachment 189292 [details] [review]: I like the documentation parts. But I do not understand why MOD_ONLY_THIS would be needed at all.. The backends can always check if the master object exists and ensure an EX-DATE is set isn it? which would be better.
Review of attachment 189293 [details] [review]: Looks good. please commit to master and stable branches.
Review of attachment 189298 [details] [review]: looks good. please commit the patch to master and stable branches.
(In reply to comment #10) > Review of attachment 189292 [details] [review]: > > I like the documentation parts. But I do not understand why MOD_ONLY_THIS would > be needed at all.. The backends can always check if the master object exists > and ensure an EX-DATE is set isn it? which would be better. I can now understand the intention for this after looking at all patches. I want to know how it would help the client, to avoid regenerating the instances from the master object ?
Review of attachment 189292 [details] [review]: MOD_ONLY_THIS is needed in those cases where "ensuring an EX-DATE is set" is *not* what the client wants. Evolution always wants the traditional semantic (add EXDATE), but SyncEvolution and KCal-EDS don't.
Review of attachment 189292 [details] [review]: After the irc discussion, i can understand the use case. Please commit the patches to master and stable branches. It is useful for a case like undo. Though it adds an additional flag, i think it wont affect the behavior of the old clients. Please commit the patches to master and stable branches.
(In reply to comment #15) > After the irc discussion, i can understand the use case. Please commit the > patches to master and stable branches. Done. Applying it to all branches (master, gnome-3-0, gnome-2-32) wasn't easy because they have diverged. I already had to correct one mistake on the gnome-3-0 branch. Please scream, eh, point out polite when I broke something. I'll keep this open until we have confirmed that it is all properly done.
(In reply to comment #16) > I'll keep this open until we have confirmed that it is all properly done. I would go the other way, reopen if it have regressions, because people tend to forget of bugs.