Re: [Opensync-devel] [PATCH] Important fix to libgcal-0.9.5

[Chris F. <cd...@fo...>]

On Sun, Aug 29, 2010 at 12:12:29PM -0400, Adenilson Cavalcanti wrote:
> Chris
> 
> I've checked the patches, and I got to say that I liked it (you even
> remembered adding the examples from libgcal website, this is something
> I was supposed to do ages ago...).
> :-)

Thanks!


> I'm just not sure about this one:
> http://repo.or.cz/w/libgcal/libgcal-cdf.git/blobdiff/6f74f867f1af0ddafa8bc96a63d3a664c09f5605..b8096cbef66527a0ec778dbf40cc47b5af202501:/src/gcal.c
> 
> Why add a new function to delete an event if gcalendar.h already has it?
> 332 int gcal_erase_event(gcal_t gcal_obj, gcal_event_t event)?

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.

When I'm ready to delete an entry, all I have is the edit_url.  When
reading libgcal's source code, it seemed that the library just copied
the edit_url from the gcal_event_t to do the delete.  In fact, in one
function, it actually created an empty type, filled in the edit_url, and
then called delete.

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?

Anyway, that was my problem, and why I added the new API.  It seemed
like the library went to great lengths to copy the edit_url around, when
passing it in as an argument was all that was needed.


> http://code.google.com/apis/calendar/data/2.0/developers_guide_protocol.html#DeletingEvents

This says I have to retrieve the old one first, and then delete it.
Is this required?


> So, after we worked this minor issue, your patches are clean to go
> into libgcal mainstream. Again, if you can, I suggest to base yourself
> using the gitorious repository, since it has a better and cleaner
> interface for me to handle merge requests.

If you add my repo.or.cz url as a remote in your own repository, you can
handle merge and diffs straight from the command line.

I don't like gitorious, since it depends on javascript too much.  I couldn't
even find the git pull URL without javascript, which is kinda sad. :-)

But I've added the gitorious repo as a remote for me, so I can base all
my work on your latest code.  That's the nice thing about git... it doesn't
matter where people host their repos.

Thanks,
- Chris