Hi Eduardo, I believe your assumptions are correct - that <atom:published> is intended to be a creation stamp that does not change. The Atom RFC doesn't seem to enforce it as an immutable creation date though:
"Typically, atom:published will be associated with the initial creation or first availability of the resource." I'm looking into our implementation to see if that is the behavior of our Data APIs. Like you suggested, it might be somewhat API-specific. I will let you know what I find out. Cheers, -Jeff On Aug 21, 8:28 am, Eduardo Habkost <[EMAIL PROTECTED]> wrote: > Hi, > > I have been working on synchronization software for Google services, > and I have a question about the 'published' element on GData entry > elements. > > My question is: can I expect the value of the 'published' element for > entries on GData to never change? Or there are cases where the value > of the field may change over time? > > If it never changes over time, do I have a guarantee that if I do make > two queries, A and B, for every element that appears on query B but > not on query A (in other words, it was created between query B and > query A), it will have a value of 'published' higher than the value of > 'published' of every element that appeared on query A? > > If the answer is 'it depends on the service', do you know the answer > of these questions for the Google Calendar API? > > [end of questions] > > For people who want to understand exactly why I ask this, below is an > overview of the problem I am trying to solve, and why I plan to use > the 'published' element, if the requisites above are satisfied: > > On the synchronization software, I need to query for all entries that > were added, deleted or modified after the last synchronization. This > is easily done by storing the value of the highest 'updated' field of > las synchronization and using 'update-min' query parameter. > > However I need to differentiate between items that were created since > last synchronization and items that were modified between last > synchronization. I think I could use the 'published' element to know > that, if I store the highest 'published' value since last > synchronization. Then I would just need to look at the 'published' > elements to know which items were created after the last > synchronization and which ones already existed. > > But this would work only if the two requisites in the beginning of my > message are satisifed: 'published' should never change, and new items > should never have a 'published' date lower than the items returned by > queries made before the item was created. > > I know there are ways to work around that if the requisites are not > guaranteed, I could just keep the list of all IDs that were already > seen since last synchronization. But I would like to know if I really > need to do this. I would need less state information be kept if I can > simply trust the 'published' field for that. > > Regards, > > -- > Eduardo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Data Protocol" 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-help-dataapi?hl=en -~----------~----~----~----~------~----~------~--~---
