Re: [Evolution-hackers] [EDS PATCHES] ecal item semantic (was: [Fwd: Re: e_cal_remove_object_with_mod() + empty rid: semantic?])

[chen <pchenthill novell com>]

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 ohly 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