GNOME Bugzilla – Bug 316342
Inconsistencies in behavior of various calendar backends
Last modified: 2015-06-03 09:41:13 UTC
Version details: Also 1.2.x Distribution/Version: SUSE 9.3 and 10.0 When trying to use the ECalView APIs, there is a large amount of inconsistency in their notifications. I am trying to use the e_cal_get_changes() to get changes when my application starts up, and then use ECalView to get notification of all subsequent events. As far as I can tell, e_cal_get_changes() does not work at all for the contacts:/// URI or any webcal calendar, because they appear as having no items when I call e_cal_get_changes(). After setting up the CalView, I get ObjectsAdded signals for all of the items in contacts:///. For webcal calendars, I get ObjectsModified signals for every item (which is often hundreds), and, in one case ObjectsRemoved signals immediately afterward for all the items.
Created attachment 52245 [details] Beagle log showing this behavior This is a beagle log with a lot of debugging output which shows the problem. Note how "file:///home/joe/.evolution/calendar/local/system" correctly has 4 added, 0 changed, 0 removed. This change notification doesn't work for any of the other calendars (calendar:/// and 3 webcal:/// URIs). Then notice the insane number of events after the fact, none of which I think should happen.
Likewise, if you call e_cal_get_items (cal, "#t") on each of the calendars, the system calendar correctly reports 4, and contacts:/// and all the webcal calendars report 0. I'm not sure if I am supposed to, but I don't receive ViewDone signals at all for the subsequent signals, like I do with the SequenceComplete signals in EBook.
e_cal_get_changes is not yet implemented for both web as well as contact backends. Web calendars will be reloaded after every refresh time interval, whatever has been specified while configuring a web calendar. So if the event is already present a modified signal would be emitted. A check is not made here whether the event has been modified. ViewDone signals are implemented only in groupwise backend as of now. I suppose you mean e_cal_get_object_list (e_cal_get_items), we need to verify this. Thanks for reporting.
Assigned to dinesh.
ViewDone is definitely emitted after the initial batches are sent. Look in the log I attached for "View done". Am I right in assuming that the ViewDone signal is not functionally equivalent of EBook's SequenceCompleted signal? Given the potential size of contact and webcal calendars, adding e_cal_get_changes() for those seem very important for consumers. Lastly, the ObjectRemoved signal for one of the three webcals is problematic. Any ideas on that one?
removing old target milestone, retargetting to 1.7. chen: *poke*
Ping on this? It's been a year and a half since I've filed this, and I still get inconsistent behavior with webcal still the most broken.
Am sorry I had completely missed this. The view done is not emitted in case of webcal which needs to be fixed. W.r.t the ObjectRemoved signals in webcal, the current implementation removes the entire calendar events every time a refresh happens or at the time of loading the calendar. We need to check the last modified time of an event instead of removing and re-adding. I will provide a fix for both of the issues.
Chen, ping, is this bug still valid ?
yes it is still valid.
Chen, is the thing left here about comment #8 "only"? I can try to help, if you agree.
The get_changes() API is gone in 3.12.x/3.16.x/git master, thus I'm closing this. The part about re-add will get fixed in the future, most likely together with a meta-backend work.