GNOME Bugzilla – Bug 629603
Allow calendar refresh on demand
Last modified: 2010-09-29 10:16:26 UTC
I'm running evolution 2.28.3 on Ubuntu 10.04, and met same problem as described in https://bugzilla.redhat.com/show_bug.cgi?id=606168 I'm reporting here to gain attention to fix it.
Thanks for a bug report. If I got it right you've 2.28, but the fedora reported has 2.30, and you see the same issue: Successfully set up Evo 2.30 on two different computers (PC1 and PC2) to connect to MS exchange account. Start up Evo on PC1, and make some calendar appointments on the exchange calendar. Close Evo on PC1. Start up Evo on PC2, see the appointments made by PC1, then add some more calendar appointments to the exchange calendar. Close Evo on PC2. Start up Evo on PC1 again. See the first appointments in the exchange calendar made originally by PC1, but do NOT see the newer appointments made by PC2. Close Evo on PC1. On PC1, open 'System Monitor', find and end/kill the 'e-calendar-factory' process. Start Evo on PC1, go to calendar (e-calendar-factory process starts up again), and now successfully see the appointments made by PC1 originally and the newer appointments made by PC2. Note - closing Evo does not seem to always close 'e-calendar-factory' (used elsewhere?? eg. appointments/tasks on gnome panel clock?), and when Evo starts up again, if 'e-calendar-factory' is already running, then e-calendar-factory does not go to check if the exchange calendar has changed since Evo was last run. Killing e-calendar-factory forces it to refresh the exchange calendar when Evo starts up again. Note - the same effect applies to Tasks on the exchange account. Note - Not known if this issue occurs when Evo is left running on PC1 the whole time, while exchange calendar is changed via PC2. At the very least, each time Evo starts up, e-calendar-factory should refresh exchange calendar and tasks irrespective of whether e-calendar-factory is already running on any PC. Perhaps e-calendar-factory should also be doing regular update checks??
I searched the code briefly, and I see there is no UI to define a refresh interval, like with an On The Web or CalDAV or any similar remote calendars, but there still is a way. The default timeout for a cache refresh is 10 minutes, and one can redefine this by an environment variable GETQM_TIME_INTERVAL who's value is a number, how many minutes wait till the next update of a cache. This environment variable should be defined before e-calendar-factory is run. I suppose that it's rather meant for debugging than for regular users. Anyway, from the above, if you'll wait for those 10 minutes, then you should see he event shown, same as when you closed e-calendar-factory. Maybe except of one difference, bug #625115, where with 2.30.x or 2.28.x one would reopen evo sometimes. I believe this is mostly fixed in 2.31.92, and considering the default refresh interval being in 10 minutes is also reasonable, then it should be fine with that and later version. Sounds good?
I'm the redhat bugzilla reporter. I understand you are saying default Evo 2.30 already has a cal refresh every 10 mins. I did not notice that, as I did not wait that long before restarting Evo on another PC. If default Evo comes with a default cal refresh every 10 mins, that's fine by me, especially if this interval can be altered by an environment variable. But in addition, could each launch of Evo also trigger an immediate cal cache refresh? e-calendar-factory is often launched before Evo (eg logging into a new Gnome session where Clock 2.30 on the panel starts e-calendar-factory to show cal/tasks). An enhancement could be to add a UI element to change this refresh interval time. But also what is really needed is push notification functionality from the exchange server. But this may not be possible with evolution-exchange. Perhaps evo-mapi would have this??
I hoped we are actually talking about evolution-mapi, the above I said doesn't work with evolution-exchange, as I searched only the evolution-mapi code. I agree with default 10 minutes interval being a good default, and even that there might be a UI for setting this interval, but not necessary. There is a possibility to do a refresh on user's demand, by right-clicking on the calendar in the left tree and choosing "Refresh..." (which is not implemented for evolution-mapi yet). Refreshing on every source opening is not doable, it might mean more trouble than gain. I like the idea of notifications, and I would go by that way, but the experience showed that the openchange and samba4 are not thread safe, and the notifications can mean crashing, till this is saved in those libraries. Thus maybe some time later. Thus summarizing: I'll create a patch to enable the "Refresh..." popup menu option for evolution-mapi calendar sources, which may technically fix this issue.
Created attachment 170410 [details] [review] ema patch for evolution-mapi; This enables the "Refresh..." calendar popup menu option. Just note that invoking it doesn't mean the event will be shown immediately in the evolution UI, it can either be already in the update process, which may take some time before it finishes, or, when you are creating even from the OWA interface, then till it's available for MAPI fetching by the server, or, the finish of update takes a while, or, the concurrency avoidance doesn't allow any fetching until the previous, though for other MAPI calendar, is finished. For example, it takes several seconds for me.
Sorry, I was confused. I am using evolution-exchange to connect to MS Exchange server, and that was what I was talking about in both this bug report and the Redhat bugzilla bug report. I have not tried evolution-mapi. Having a refresh option on the right-click menu on the calendar name in the left tree sounds good. I'm not sure if you are saying this will also work with evolution-exchange. I suppose what I'm saying is that, for a MS Exchange calendar accessed via either evolution-mapi or evolution-exchange: -Refresh cal every 10 mins by default. Have the option to change the number of mins via environment variable and/or evo UI (or turn refresh mins to infinite ie. off). -An immediate cal refresh is triggered whenever Evolution is started (because e-calendar-factory may be already running due to another program eg gnome-clock starting it). -Having a right-click menu refresh option on the calendar name on the left tree and/or, a refresh-all-cals button at the top of Evo window. Having the refresh take several seconds is fine. Thanks for following this bug up.
Created attachment 170633 [details] [review] eex patch for evolution-exchange; OK, I see that evolution-exchange is using subscriptions on a folder, instead of timeout refresh, though they are not working for my server (might be disabled there or something). Nonetheless I add subscriptions for more events and enabled the Refresh option for evolution-exchange too.
Created commit 0519835 in ema master (0.33.1+) Created commit 7992f76 in ema gnome-2-32 (0.32.1+) Created commit fbaa11a in eex master (2.33.1+) Created commit 71fbefc in eex gnome-2-32 (2.32.1+)