Hi Mikael, I don't feel that this is a feature lacking in the API. With client-side atom:id generation, there is always the potential for conflict (as you've mentioned). The code required to handle the possible collision case would be relatively the same code necessary to handle the swapping of a client-side ID with a server-side ID at the time of publishing.
The Calendar Data API is intended to be a method for publishing events as well as querying and retrieving events from the calendar servers. The entry objects on the client are intended to be a representation of what exists on the server. There is no intention to have multiple event stores and thus the calendar servers are authoritative in their ID assignments. This behavior is specifically mentioned as a possibility in the current draft [1] of the Atom Publishing Protocol (APP), which the Google Data APIs are based upon. We currently have no plans to change this behavior. That being said, the proposal has led to some internal discussion on the topic. Although the response was not positive in this case, I'd like to thank you for making it and welcome community discussions on topics such as these. Cheers, Ryan On Dec 6, 12:14 pm, "Mikael Grev, MiG InfoCom" <[EMAIL PROTECTED]> wrote: > > Sorry Mikael for the delay in response, but thank you for the detailed > > proposal. I have a couple follow-up questions.No problem. :) > > > How do you currently persist the events when the user is offline? Do > > you store them in some sort of data store, or do you just have > > objects/serialized objects?They are stored as the type of event that we > > have (called Activity). > The CalendarEventEntries are basically converted back and forth between > our Activity type and the CalendarEventEntry as they are read/written > from your server. > > > Perhaps the answer to the first question will answer this one :) -- > > but, why does the internal ID need to be stored in an ExtendedProperty? > > Couldn't you just have an offline mapping of the IDs?This was the second > > approach that we could do if we didn't want a > replacement run for IDs on our internal server. It means that we aren't > using your ID at all and are storing our own event ID in an > ExtendedProperty when storing the CalendarEventEntry at your servers. > The problem then is of course that you can't Query for this ID which is > very limiting. > > Offline mapping of IDs are just a disaster waiting to happen. It means > that the mappings needs to be maintained in transactions (maybe between > servers) and with error tolerance and such. It will add a whole slew of > new problems and make the solution more complex. > > I have a question for you as well: > Why aren't you using the ID set with Entry.setID(..)? It seems only > natural to me that the one that is creating the event is the one > choosing the ID. > > Cheers, > Mikael > > > For others out there writing sync apps -- I'm curious to know how you > > have handled this situation? > > > Thanks again! > > > Cheers, > > > -Ryan > > > On Dec 6, 10:38 am, "Mikael Grev, MiG InfoCom" <[EMAIL PROTECTED]> > > wrote: > > > > I would be glad if I got a comment from Google on this one since it is > > > IMO a pretty important question if you are creating an offline > > > application to Google Calendar. > > > > Cheers, > > > Mikael Grev > > > > On Dec 2, 10:58 am, "Mikael Grev, MiG InfoCom" <[EMAIL PROTECTED]> > > > wrote: > > > > > Hello, > > > > > We're creating an application that is connected to Google Calendar but > > > > it will also work offline. I have problem with ID generation. As I > > > > understand it there is no way to decide the ID of created events from > > > > our side. This is a problem for us since when working offline and when > > > > the user creates an event we must create an interim ID. This event can > > > > then be sent around among our internal servers. When the event later > > > > gets persisted to Google it will get another Google generated ID. We > > > > must then change the ID on our internal so that synchronization > > > > wouldn't be a problem. > > > > > An alternative would of course be that we had two IDs. One internal and > > > > one Google ID. This is not very clean though and it also is a problem > > > > since our internal ID must be stored in an ExtendedProperty which isn't > > > > searchable. This means that we would have to get the whole calendar if > > > > we just wanted to look up an event using our internal ID. > > > > > I see no good way to solve this problem. I feel that the Google > > > > Calendar API was created only for online operation and a few important > > > > use-cases has been left hanging for on/offline usage. > > > > > I would like to propose that the setID() actually worked and we could > > > > set the ID. I wouldn't mind if there were strict rules how this ID > > > > should be created. You could also have a static createID() method that > > > > returned a valid ID (without contacting the server of course). If the > > > > ID is already in the database the create process should return an > > > > error. > > > > > Please consider this request. > > > > > Cheers, > > > > Mikael Grev > > > > MiG InfoCom ABwww.migcalendar.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Calendar Data API" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-calendar-help-dataapi?hl=en -~----------~----~----~----~------~----~------~--~---
