|
From: Adenilson C. <cav...@gm...> - 2010-08-30 17:22:09
|
Chris I will answer inline. > Ok, here's the background on why I added that. It might be my lack of > knowledge about the API that made me think I needed it. > > In the google-calendar plugin, I'm storing all three items for every > entry: the ID, the edit_url, and the etag. Using the edit_url and the > etag together was the only way I could get it to work. Everything else > I tried just ended in frustration. Just the edit_url should be enough. > The event type seemed to me to be an opaque type. i.e. I'm not supposed > to access the internals directly, right? So if all I have is the > edit_url, how should I delete with gcal_erase_event(gcal_t, gcal_event_t)? > Perhaps I'm supposed to call set_url() first? > Exactly, you should set the edit url in the gcal_event_t 'object'. > This says I have to retrieve the old one first, and then delete it. > Is this required? > This means that once you have downloaded the event, if this event has not changed on the google server, you only need the edit_url to delete it. If something has changed in the server side, then you need to query for updates and use the new edit_url. The changed method is something that I can't accept, because it will break with ABI. I used the concept of 'objects' in libgcal to hide implementation details from users and ensure that all memory allocated by the library would be freed by it. I've inspected your patches and merged them into libgcal main repository, it will be part of the 0.9.6 release (it has not any new feature, only bug-fixes). I hope that this fixes the opensync case (and hopefully pretty soon the distributions will start to use this new version). Best regards Adenilson |