While i do understand your disappointment, i think your critic is a tad harsh ...
Note there is an open bug against the calendar server team in regards to querying extended properties. That point is a, IMO, valid, and as you note, it would solve your issue. Solving your issue does not require entirely new capabilities, but fixing an existing problem, one that is ackknowledged. Frank Mantek On 12/9/06, Mikael Grev, MiG InfoCom <[EMAIL PROTECTED]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
