GNOME Bugzilla – Bug 494394
No way for the user to refresh a calendar
Last modified: 2009-12-01 07:05:49 UTC
Please describe the problem: I added a calendar 'on the web', but loading the calendar failed (I typed the address incorrectly). I corrected the address in the calendar's properties, but I can't find any way to tell Evolution to try downloading the calendar again. I have to quit and re-launch evolution for it to try again! Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Downstream bug https://bugzilla.novell.com/show_bug.cgi?id=175331
Created attachment 130157 [details] [review] proposed eds patch for evolution-data-server; cal backend factory stores backends by their URI (and kind), thus when one changed URI of the source the factory created new backend, which wasn't assigned for all the queries as the last backend, furthermore, with this playing one would make as many backends for one source as many times he/she changed url in preferences. This patch does couple things: - distinguish backends based on source uids (and kind), rather than by uri - on source change update also backend's source and uri - in http backend empty cache on error (it's done in a public function, because I feel confident we will use this in other backends too) With that above Evolution reflects actual URI in a calendar view, not after restart. This is not the same as some explicit "Refresh" menu item in UI, but is necessary to let it work. Aka, call it the first step.
Of course, there should be enough to check and uncheck calendar in the left tree and it should update itself, but it isn't at the moment.
Created attachment 130189 [details] [review] proposed eds patch ][ for evolution-data-server; Do not cause double free.
There are some more critical properties that a backend depends on such as url, username, auth etc. Whenever any of these changes EDS backends does not get notified. What about doing this way, * As Esource changes are not propogated, maintain a ESourceList in e-data-cal-factory which watches Esource changes. * Whenever a ESource is changed, identify the backend and notify the backend that some property has changed in the ESource. * Backend can now decided what to do by comparing the old and new esource properties. (or we can also think of doing it in a common way to all backends, but it depends and need to think more) * If any property such as url or user name is changed. Backend can stop all the background operations, empty cache and reload the cache. * If say some property such as refresh interval is changed, it can just change the time interval of the time-out loop. This way one need not check/un-check his calendar to see the changes.
BTW i like the use of Esource uid instead of uri for the hash table and e_cal_backend_empty_cache.
Actually, you are notified of changes in ESource by evolution itself or something (I didn't check the exact place where the other is invoked), thus the ESourceList might be redundant here (but it needs more testing). The other things are done and/or possible with the above patch too, because of the ESource change propagation to the backend source, which invokes "changed" signal, and if the backend listens to this signal, it receives it and is able to make proper changes as it wish. Note, maybe I placed the empty_cache to wrong file, shouldn't it be rather in e-cal-backend-util? I'm not sure here.
Esource changes are notified through esource-list. Please check who triggers "changed" signal on Esource. Esource does not watch not gconf changes, only ESourceList does. Thats the reason i mentioned DataCalFactory should listen on SourceList changes. Please correct me if am wrong. Its better in ECalBackend itself i guess. But we should prolly give the derived classes a chance as exchange and file backend does not use ECalBackendCache.
(In reply to comment #8) > Esource changes are notified through esource-list. Please check who triggers > "changed" signal on Esource. Esource does not watch not gconf changes, only > ESourceList does. Thats the reason i mentioned DataCalFactory should listen on > SourceList changes. Please correct me if am wrong. Yes, I know that ESourceList takes its part of this, but it just takes care of GConf part, the e_source_update_from_xml_node emits ESource's "changed" signal at the end of the function, if ESource actually changed.
Yeah, so the propagation comes from ESourceList->ESourGroup->ESource :)
Created attachment 136278 [details] [review] proposed eds patch ]I[ for evolution-data-server; OK, I did it with ESourceList-s. Just to summarize: a) EDataCalFactory uses source's UID and backend's kind as a key, not URI b) factory has its own ESourceList for each kind of backend and listens for changes. On the "changed" signal emit checks all opened backends and updates their sources, which invokes its own "changed" signal, if changed c) factory has stored backend list divided into types for easier manipulation d) ESource doesn't emit "changed" signal when relative_uri is present in the XML node it updates from, and also updates absolute_uri appropriately e) ECalBackend also listens for ESource "changed" signal, to update its internal 'uri' member (there was a function for this before, but it couldn't work) f) only the http backend listens and does something on ESource change. Other backends are supposed to be updated g) e_cal_backend_empty_cache left as before h) do not unlock when not locked in a factory (search for cleanup2) As far as I tested it, changing URL of a web calendar reloads it as soon as it knows about the change.
For the explicit invocation of "Refresh" on a calendar, I would suggest to add new static capability indicating the backend supports such method, and enable the popup menu item in the calendar view only for these calendars. The calendar backend will have new method, for refreshing. It will do probably nothing when in offline, but that all is a question for a backend itself. Nonetheless, all this is a bit tight to bonobo, ORBit or whatever, then let's wait for the explicit refresh for the eds-dbus, to not make Ross too unhappy of a new change. I was also told that adding popup menu items will be much easier after kill-bonobo, thus yet another reason why wait a bit longer.
Approving the patch. I would not recommend a static capability for that. New method in ecal is definitely required. The backends can decide to implement the virtual function.
Created commit 1fc3631 in eds master (2.27.3+) I'm not closing it, as the comment #12 is still on its way.
*** Bug 308036 has been marked as a duplicate of this bug. ***
From the bug #308036: > Create several web calendars with a refresh time of 1 week. > Set evolution offline. > Start tcpdump port 80. > Put evolution online. > Watch tcpdump have a lot of port 80 traffic to the webcal hosts, even though > calendars _should_not_ be newly updated. Thus when there will be an explicit function to refresh a calendar, then together with it there should be improved a refresh counting for remote calendars to remember their last update time and invoke refresh on start or going online only when the time from the last update is greater than the refresh time set.
This patch introduces regression, for clients using e_cal_system_new. These create uids on every call. They aren't associated with any real ESources. Mostly used in mobile platform. (Dates, e_book_system_new for Contacts, Moblin etc).
I think you meant e_cal_new_system_* functions, and also e_cal_open_default, which can use them. The proper fix is probably to change e_cal_new_system_* to read source from a source list, and only when not found the system calendar there, then crate a fresh new one and save it to known sources. Do you want a patch for that? By the way, e_book_system_new should not be affected of this patch, here was changes in calendar only. I'm wondering, what kind of regression is it introducing? I see that the system ECal-s, their backends, are opened multiple times, but it should sync between each other. Isn't it?
Created attachment 142687 [details] [review] proposed eds patch (for gnome-2-28) for evolution-data-server; Chen explained me on IRC, and decided to remove the ESourceList part for stable, as the GConf is not thread safe, thus the getCal called from other than a main thread can cause a crash. Apart of that this patch tries to find a backend also based on the uri of the gives source, if not found by UID. Changes will be reconsidered for a master branch as soon as the dbus-cal will land in sources.
Comment on attachment 142687 [details] [review] proposed eds patch (for gnome-2-28) Patch looks good. Please commit it immediately to stable. Part of this patch which covers backward-compatibility should go into master as well.
Created commit da61e17 in eds master (2.27.93+) I'll create a patch for master when the eds-cal will be in.
Oh, I forgot to update this bug. The backported part about backward compatibility had been added to master within commit 937382d for bug #597157, thus only part about "have a popup menu option to refresh a calendar" reminds here.
Created attachment 148480 [details] [review] proposed eds patch for evolution-data-server; Adding routines to be able to refresh a calendar. This is done for CalDAV, WebCal and Weather calendars.
Created attachment 148481 [details] [review] proposed evo patch for evolution; UI part, to be able to invoke "Refresh" on calendars which support it.
Comment on attachment 148480 [details] [review] proposed eds patch committed for 2.29.3. id - 523d5a9d3116e242ad2f8cd4d140c4c278933246
Comment on attachment 148481 [details] [review] proposed evo patch commit id - b9f0119ef5fb0a575253f9e3f1d3a5107ebc47c7
It would be good to have the refresh implemented for backends such as caldav, web cal, exchange, groupwise etc. which interact with server to provide frequent updates. Since these components interact with the UI a lot, would it be good to have a ECalView parameter through the API to let the backends notify the progress to the UI? Would be good to have this api integrated with SEND/RECEIVE which would enable refreshing multiple calendars in a single go.
(In reply to comment #27) > It would be good to have the refresh implemented for backends such as caldav, > web cal, exchange, groupwise etc. which interact with server to provide > frequent updates. As I wrote above, it is for CalDAV, WebCal and Weather calendars at the moment. > Since these components interact with the UI a lot, would it be good to have a > ECalView parameter through the API to let the backends notify the progress to > the UI? Hmm, it sounds good, though I'm not sure how to achieve this, as it is usually a two-way process, fetch files from the Internet, parse it and update local cache. You can also close evolution and the fetch will be running in the background, in eds. > Would be good to have this api integrated with SEND/RECEIVE which would enable > refreshing multiple calendars in a single go. I'm not much sure here, I wouldn't expect such functionality under send/receive in calendar view. Nonetheless, for all the above, let's have a separate bug for that, not this one, which I'm finally closing as fixed.
(In reply to comment #27) > Would be good to have this api integrated with SEND/RECEIVE which would enable > refreshing multiple calendars in a single go. Doesn't [open]SUSE relabel that button as "Get Mail"? (Which I like better, personally.) Send/Receive seems like the right place for it from from an API standpoint. But it brings up that old nagging question of what to label the button. And does it still make sense for "Send / Receive" or "Get Mail" to appear in all the components? Or should Calendar, Tasks, and Memos have a "Refresh" button in its place? I don't know the right answers. We could use some usability guidance on this.
hmmm thinking about groupwise/exchange and added all the backends to the list, my bad. Gave a thought on the notification to the UI and I feel we need not do more there. Once the client starts a view, the live queries are stored in EDS. So any notification from the backend will notify all the clients. Nothing needed to be done there. On Send/Receive Vs Get Mail, am not sure really. There are mixed opinions there :) So one of the arguments was that Get Mail should not trigger sending mails. It would not be good again to have a button, send mails :) In any ways Send/Receive is definitely not the best one. Using "Refresh" for Calendar, Tasks and Memos - +1 from me :)