Hello Ryan, > 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.
Creating unique IDs offline is not rocket science but common knowledge, IMO. Collisions with a decent algorithm is only a theoretical problem that is much less likely to occur that general bugs. This makes your second sentence void since it would be a non-issue. :) > 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. What this actually means is that you do not support offline operation. > 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. Thanks for trying. :) I know now that I must set the ID in an ExtendedProperty. If you could add support for make a Query on these properties the problem would be solved for me in a good enough way. If not, then for every request of a specific ID I would have to get the whole feed and filter out the intended ID locally (slow). This is what I do now but it won't scale. I must also say that I am a bit disappointed about this. It would be a rather simple thing to add with no problems on your side and I promise you it would make the offline/online use case a lot simpler. I get the general feeling that the Client API is actually architectured by server/web experts and not by developers in the client application arena. ;( Cheers, Mikael Grev MiG InfoCom AB > 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 -~----------~----~----~----~------~----~------~--~---
