Difficulties of synchronizing google calendar with google data protocol.

First I want to emphasize, that it is important to user the most recent version of clients libraries, because google protocol is still develeped and some version are quite insufficient (especially that included in debian linux).

Google data protocol currently have three versions. I have only considered using version 2 and 3. I suppose that version one is quite obsolete. Version 3 is based on JSON, which is great because no parsing is needed, but that version provides no support how to chain commands together in batches. Also the client libraries does not include the last version support. Running commands in batches is quite important because there is quite big net roundtrip for each request. So without batches you are forced to implement sending asynchronious requests. I am not sure if one batch request counts as one in google limits, but their are quite comfortable. Because I have been in developping the synchronization through the protocol version 2 when the next version was introduced I stucked with the older version so I hope that some information will hold even for next version.

Major obstacle in protocol version 2 is that recurrent events are represented in diffferent format than normal events. Normal events are represented in atom xml, which is parsed by GData library. Recurrent events is represented in iCalendar format and you have to parse it yourself. Therefore you have to implement two parsers and writers and not only one.

Next obstacle is that recurrent events can have exceptions. In iCalendar that exceptions is represented by EXDATE, what is sillently ignored by google. The Google calendar web aplication fortunately understands but fails to mark. So it is left to you. When you remove one occurance of event from recurrence or update it, the new event is created which has link to recurrent event which modifies. The original event is not modified - its etag remains same so without founding the recurrence exception you do not even know that, the original event recurrence does not hold. I came even to situation where the original event does not existed, but the recurrence exceptions was still accesible. Its up to you how you we will represent such behaviour in your data model. Moreover I forget to mention that when you delete original recurrence all exceptions are deleted as well and same hold even for some modifications of original event.

Third obstacle is that the google sometimes lies to you, so you have to learn to ignore problems with denied authorization for authorization values which does not changed and starts to work in the next request. Also sometimes you are redirected elsewhere, but stubborningly replying requests helps :).

The last small obstacle is that you cannot undelete or modify deleted items on Google. I am solving it by creating new ones instead of deleted ones.

So you can say, google also provides CalDAV access, why not go with it? Yeah good try, but you will also meet all previous mentioned obstacles. Not to mention that authorization will fail to work not for one request but for days and after some time it will start works without any change. And of course forget authorization with OAuth, you will have to send plain text password. A big "no way" for any server. At least the google will inform a user that your server tryies to access his account with his credentials. So prepare plausible explanation that you have not let his password to be stolen.

Should I write more about google calendar?