3 messages in com.googlegroups.google-calendar-help-dataapiClarification request: Events moved b...| Subject: | Clarification request: Events moved between calendars![]() |
|---|---|
| From: | rk (r....@leapbeyond.com) |
| Date: | 04/22/2006 06:08:14 AM |
| List: | com.googlegroups.google-calendar-help-dataapi |
I didn't see anything in the API documentation defining what happens when events are moved between calendars (apologies if I've missed something!).
From my testing, the event simply disappears from the original feed, and is moved to the new feed - and assigned a new ID. The original feed has no indication that the event has moved, and the event in the new feed has no link back to the original (now erased) event.
This could create a problem for synchronizers.
First, lets consider a synchronizer that's only paying attention to the original feed. It won't see a #canceled event, so the item won't be removed from the third party calendar. The only way for the synchronizer to know the item has been removed, is to search through the entire feed (or at least up until the original published date for the event), which kind of defeats the purpose of delta sync.
Later, if an update is made in the third-party calendar, what is the synchronizer supposed to do? A bad synchronizer might attempt to recreate the event on the Google side, thus causing duplicate events in the user's Google calendars.
Next, let's consider a synchronizer that's watching both feeds. As far as its concerned, the moved event has a brand new ID, and so it will create a new duplicate event in the third-party calendar.
There are a few more issues here I haven't gotten into, but I think this is enough information to start discussion.
One approach to solve this might be to set the event status set to #canceled (see footnote) in the original feed, and introduce some new metadata pointing to the new item. This way synchronizers only monitoring one feed will delete the event from their calendar, while smarter synchronizers still have a breadcrumb to go follow.
Of course, even this approach has some shortcomings from a synchronizer's point of view. (e.g. Think about what happens if the synchronizer processes the destination calendar before the original one, or if an item hops between a few calendars).
On the flip side of things, if I'm synching multiple calendars in a third-party app to multiple Google ones, it might be convenient to have a .MoveToCalendar() method in the API that can accomplish the move without loosing any new metada Google has added to their event schema since I wrote my application.
I'm sure there are people on the API team who have thought about these issues more than I have; I'd very much like to hear your remarks on the topic. In the long term, it would be great if a synchronization "best practices" guide could emerge that more thoroughly examines all the issues.
Cheers,
-Richard
*Footnote: If we don't want to advertise to legacy systems that the event is canceled (since the user didn't actually delete it), we can use a new value, e.g. #moved, or even a whole new field.




