GNOME Bugzilla – Bug 572176
Allow Local iCal Files To Be Selected As Calendar Source
Last modified: 2012-08-10 12:12:00 UTC
In the same GUI as the "On The Web" calendars, please allow for entry of file:/ to point to .ics files. These would be read-only sources. If they want to add to them, they should be using "On This Computer". Otherwise we will have to account for record locks and writes from multiple users (bad). I also propose that the string "On The Web" be changed to "iCal" to better indicate the type of calendar, and not the delivery mechanism to deliver said calendar. Other information:
should it be treated as an enhancement ?
Yup, it is an enhancement. David, you changed it a bit, I was thinking of the enhancement of the "On This Computer" only, add there two new GUI elements, one for the URL, other for the forcing to be readonly. But you propose changing two backends, a) allowing file:// for the webcal calendars (opens always as readonly) b) allowing enter custom URL for local calendars (opens in read/write mode) The a) makes sense, especially when renaming group name, but it also brings some disk overhead, as the webcals are cached on the local machine, whereas readonly local calendar will just read the underlying file directly, no caching at all. Also, as Matt suggested, we will be able to use a GFileMonitor, to listen for changes when this will be done "On This Computer" backend. (Honestly, I suppose to allow entering any url usable with a GFile there, thus it could be also a remote file. It'll also force the readonly mode when the file will be set as readonly, regardless of user's choice in preferences of the calendar. I also heard that GFileMonitor doesn't work everywhere, but that's not a question for evolution.) With the other thing, file locks, you've right, nothing like that will be used there, let's consider this as kind of user's fault. :)
You know that I'm open to ideas and brainstorming. For us, option "a" is the best solution. I would want the calendars to follow the same logic as "On The Web" and only update in the timeout period. We sometimes have 300 concurrent Evolution sessions running, and I don't want them all watching for file changes and all updating at the same time. Those types of things will cause a huge server load. Another more radical long term idea is that possibly "On This Computer" + "On The Web" + "Local iCal"s should all be merged into one GUI and section. All of them are basically the same thing, with just different transports; but the 'calendar type' is the same.
Created attachment 129683 [details] [review] proposed eds+evo patch for evolution-data-server + evolution; only the webcal part, now one can enter any URI there, those with http and https will be turned to webcal, but anything else will be kept. There is no mounting or anything on the GFile, thus the file should be accessable. Note: I merged those two patches by hand, hopefully didn't break it.
I would like this to be part of the File backend than the On the Web backend to maintain the abstraction. Probably to avoid all the clients to read the files for changes at the same, we can have a refresh interval for the calendar. Some esource property can be used to note that the calendar is a link to file on this computer.
Created attachment 136223 [details] [review] proposed eds patch for evolution-data-server; As I mentioned above, no checking for conflicts when writing. Also, file content has precedence from the in-memory data when reloading.
Created attachment 136224 [details] [review] proposed evo patch for evolution; As discussed with Chen on IRC, this will be probably done in some iterations, so here's the first step.
Over-all the patch looks good. Please commit the patches immediately. Please announce the UI and string changes to the Instead of using refresh_gone_cond, could we just have a g_thread_join in finalize ? can we have a boolean refreshing to know if the refresh is in progress and skip it instead of using the guint refresh_skip ? Was just wondering whether there is a reason for maintaining the number of skips.
*to the doc and translation teams.
Created commit f95e0a9 in eds master (2.27.5+) Created commit ff186e2 in evo master (2.27.5+) - E-Mail sent. - Note I changed the ESource part slightly.
(In reply to comment #8) > Instead of using refresh_gone_cond, could we just have a g_thread_join in > finalize ? Yes, that should work too, just make the thread joinable and instead of remembering the cond pointer remember the thread pointer. I have a similar approach in CalDAV, and as it was working fine there, then I adapted it back here. > can we have a boolean refreshing to know if the refresh is in progress and skip > it instead of using the guint refresh_skip ? Was just wondering whether there > is a reason for maintaining the number of skips. The refresh_skip is used to indicate that we saved the file, thus when the custom_file_changed will be invoked we will know to not reload all the file, because we changed it. It seemed to me better to count them, I'm not sure why now. Do you want to change both, Chen?
(In reply to comment #11) > Do you want to change both, Chen? Chen: ping - can this be closed or is there something remaining?
*** Bug 337512 has been marked as a duplicate of this bug. ***
It works in current stable (3.4.x), thus I'm closing this as such.