GNOME Bugzilla – Bug 652174
libecal: Allow async storing
Last modified: 2011-10-19 20:22:11 UTC
libecal should allow the caller to request storing of data without blocking on processing of the data. It should notify the caller when the data has been stored, or when processing has failed. These functions may require async versions: * icalcomponent_new_from_string() * e_cal_modify_object[_with_mod] * e_cal_create_object() We hope to provide a patch for this eventually.
icalcomponent_new_from_string() doesn't block.
Created attachment 192544 [details] [review] Patch to add _async() variants of methods to modify the calendar [targets meego-eds] As Ross mentioned, icalcomponent_new_from_string() is not an ipc call, well, it only blocks in as much as it needs to parse the string before returning (if I've read the code correctly...) Are these ical strings immensely huge at times ? (does there need to be an async method to go and parse a mile long calendar string in a thread and notify the user when it's ready ?). This patch is available now on 'openismus-work' branch: commit 4c45a2c07dfb9f6f0fca3ed8d4e372603ed3105f Author: Tristan Van Berkom <tristan.van.berkom@gmail.com> Date: Sat Jul 23 18:05:32 2011 -0400 Allow asynchronous storing of data in ECal. Patch adds the functions: o e_cal_create_object_async() o e_cal_modify_object_async() o e_cal_remove_object_async() o e_cal_remove_object_with_mod_async() And updates the test cases to test the _async() variants: calendar/tests/ecal/test-ecal-create-object.c calendar/tests/ecal/test-ecal-modify-object.c calendar/tests/ecal/test-ecal-remove-object.c Addresses bug: https://bugzilla.gnome.org/show_bug.cgi?id=652174
Note: thankfully this patch need not be ported to master, the ECalClient apis already have sync/async variants for these.
(In reply to comment #2) > As Ross mentioned, icalcomponent_new_from_string() is not an ipc > call, well, it only blocks in as much as it needs to parse the string > before returning (if I've read the code correctly...) Correct. > Are these ical strings immensely huge at times ? (does there > need to be an async method to go and parse a mile long calendar > string in a thread and notify the user when it's ready ?). I don't think we need an asynchronous version of icalcomponent_new_from_string().
So this is just waiting for review by a maintainer of the gnome-2-32 (or meego-eds) branch.
Patrick, can we just drop the changes for gnome-3-32 and meego-eds now? Or is there a chance that this work will still be used?
(In reply to comment #6) > Patrick, can we just drop the changes for gnome-3-32 and meego-eds now? Or is > there a chance that this work will still be used? Please drop it. If there is a need, we'll deal with it as it comes up.