After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 692361 - e_cal_client_get_free_busy() broken
e_cal_client_get_free_busy() broken
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Calendar
3.8.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2013-01-23 09:25 UTC by Tristan Van Berkom
Modified: 2015-07-15 10:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
evo workaround patch (1.55 KB, patch)
2013-04-19 08:38 UTC, Milan Crha
committed Details | Review

Description Tristan Van Berkom 2013-01-23 09:25:57 UTC
As mentioned in comment in e_cal_get_free_busy() sources, this API is complicated to achieve as the free-busy list is reported via a signal on the ECalClient API (yes, a terrible API).

Opening a bug for this as it's the last reason why EDS test suite cannot pass,
fixing this is a blocker to making EDS pass make check.
Comment 1 Milan Crha 2013-04-19 06:23:28 UTC
(In reply to comment #0)
> yes, a terrible API

I would not call it a terrible API. The idea behind this API is to be able to provide free/busy data asynchronously *and* in chunks, rather than wait for complete free/busy list to be delivered in once.

In any case, you are right, Free/Busy fetching is currently broken (3.8.x, 3.9.1), the free-busy-data signal is delivered after the e_cal_client_get_free_busy() is called, while it was supposed to be delivered during this call only.
Comment 2 Milan Crha 2013-04-19 08:38:09 UTC
Created attachment 241882 [details] [review]
evo workaround patch

for evolution;

This is a workaround patch, until proper fix will be done. As it seems like an API change will be required to properly address this bug, I decided to create this workaround just for the time being, and for 3.8.x series.
Comment 3 Milan Crha 2013-04-19 08:44:55 UTC
Workarounds:
   Created commit 89b347d in evo master (3.9.1+)
   Created commit 91c44c7 in evo gnome-3-8 (3.8.2+)
Comment 4 Milan Crha 2015-07-15 10:48:01 UTC
I finally fixed this for 3.18.0 with the below commits. The current idea is that the backend can notify about received free/busy data asynchronously through the signal, but it is also supposed to claim all found free/busy data in the 'respond/finish' functions. The client is responsible to merge the objects in case it uses both the signal and the finish return value. 

Created commit_7ac9788 in eds master (3.17.4+) [1]
Created commit_8f13fe2 in evo master (3.17.4+) [2]
Created commit_5565516 in ews master (3.17.4+) [3]
Created commit_3f0722c in ema master (3.17.4+) [4]

[1] https://git.gnome.org/browse/evolution-data-server/commit/?id=7ac9788
[2] https://git.gnome.org/browse/evolution/commit/?id=8f13fe2
[3] https://git.gnome.org/browse/evolution-ews/commit/?id=5565516
[4] https://git.gnome.org/browse/evolution-mapi/commit/?id=3f0722c