On Thu, 2011-06-02 at 13:41 +0200, Patrick Ohly wrote: > Hello Chenthill! > > You are the calendar maintainer, right? Do you have some time to review > these patches? On this occasion let me add some further explanation of > the motivation for this patch series. Can you please attach these patches on to bugzilla ? I will put the comments there. I can do it myself, but there is no option to specify the author, so it would be better if you can do it..
- Chenthill. > 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. This is done so > that the file backend can replace other local storages that EDS is being > compared against. I understand that the vision of EDS goes beyond just > being a local storage, but that's irrelevant in the context of such > comparisons (unfortunately). > > email message attachment (Re: [Evolution-hackers] > e_cal_remove_object_with_mod() + empty rid: semantic?), "Forwarded > message - Re: [Evolution-hackers] e_cal_remove_object_with_mod() + > empty rid: semantic?" > > -------- Forwarded Message -------- > > From: Patrick Ohly <patrick.o...@gmx.de> > > To: Evolution Hackers <evolution-hackers@gnome.org> > > Subject: Re: [Evolution-hackers] e_cal_remove_object_with_mod() + > > empty rid: semantic? > > Date: Tue, 17 May 2011 10:58:12 +0200 > > Mailer: Evolution 2.30.4 > > > > On Mo, 2011-05-16 at 18:06 +0200, Patrick Ohly wrote: > > > I'll do it as <uid>[\n<rid>] so that entries without an rid continue to > > > look exactly like the current ones. > > > > Looks good. I ran my KCal-EDS test program which adds, modifies and > > removes events, including parent and child (= detached recurrence) in > > various orders. > > > > I am now seeing all ECalView signals that I expect and need. > > > > I also ran Evolution in parallel to the test and saw it react to all > > signals, but not quite as I would have liked. > > > > Evolution seems to interpret uid + empty rid as "all recurrences > > removed", which IMHO is wrong. It should mean "parent removed", because > > otherwise there is no way of expressing that change. > > > > For "child removed, parent not updated (= no EXDATE added)" I would > > expect Evolution to show the original, unmodified recurrence again. > > Instead it only removes the recurrence (as if EXDATE had been added). > > > > I consider this an Evolution bug which can and should be fixed > > separately. Please understand that it is currently lower priority for > > me, my main goal has to be to get EDS working as intended in EKCal-EDS, > > without Evolution. > > > > 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? > > > > _______________________________________________ > > evolution-hackers mailing list > > evolution-hackers@gnome.org > > To change your list options or unsubscribe, visit ... > > http://mail.gnome.org/mailman/listinfo/evolution-hackers > _______________________________________________ > evolution-hackers mailing list > evolution-hackers@gnome.org > To change your list options or unsubscribe, visit ... > http://mail.gnome.org/mailman/listinfo/evolution-hackers _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers