Glad to see this! I skimmed the code, but haven't had a chance to try it out yet. Are you interested in turning this in to a two-way sync at some point?

Glancing over the code (grabbed from git tonight), I think moving towards two-way should be relatively easy. In add_event(), there is a block of if/else's which generate effectively three cases:

1) Event was previously mapped but no longer exists in mcal. In this case, delete the entry from the gcal.

2) Event is not mapped. This case would stay the same, add the event to mcal (would need to update the event hash described below).

3) Event is mapped. In this case, the code currently checks to see if the gcal and mcal events differ, if so they update mcal. Instead, we could store with the event mapping a hash of the event as last synchronized with gcal. We compare both the gcal and mcal hashes against the event mapping hash. If all three hashes match, no update is necessary. if the gcal hash matches the event mapping hash, but mcal hash differs, then the event was changed locally and needs to be updated on gcal (and the event mapping hash updated). If the mcal hash matches, but gcal hash differs, then the event was changed on gcal and needs to be updated in mcal (and the event mapping hash updated). If neither the gcal or mcal hashes match the event mapping hash, then the event was presumably modified on both ends and we enter conflict resolution.

For conflict resolution, I think there are three reasonable options (user configured preference):

1) always trust server (same as gcal hash differs)
2) always trust local (same as mcal hash differs)
3) interactive

In the interactive case, neither gcal or mcal is updated, but the event and relevant details are added to a conflict table in info.db. The GUI triggers a Maemo notification that conflicts need to be resolved. When the user activates the notification, they are provided a list of conflicts, allowing them in each case to select how to resolve the conflict. The interactive mode could probably be left as a later feature, as I'm guessing most users would be satisfied with #1 or #2.

The other thing I see missing (aside from GUI) removing events from mcal when they are deleted from gcal. For that we'd need to mark off the mcal events as we see them in the gcal feed. After everything else finishes, remove the mcal events that don't get flagged.

I'm going to try and find some time to build your code and start playing with it to see how well this will work.