2006/7/6, Henry Story:
I would say that synchronization is covered. If the updated time stamp is not modified then that means that there is no "significant" change. And so there is nothing to update.
Disagree. "Online" scenario: At work, I write up a new, long, very long entry (let's call it "v1.0"). At home, I discover some small typos all over the entry. I open my APP client which synchronizes itself with the server and notice the new entry. I fix it and save. The change is not "significant". (let's call the new version "v1.1") At work, the day after, I synchronize my APP client just as I do every morning. It does not notice the entry has changed because the atom:updated has not changed. (so, I'm still with v1.0, not v1.1 at this point). A bit later, I'm told to update the entry with some new information. I start to edit the entry. My APP client GETs the entry to ensure it has the latest version (because it knows it might have missed some "insignificant" change). The change here is "significant". (let's call this new version "v2.0") This has all worked because my APP clients GET the entry before each edit to ensure they have the latest version. "Offline" scenario: At work, I write up a new, long, very long entry (let's call it "v1.0"). At home, I discover some small typos all over the entry. I open my APP client which synchronizes itself with the server and notice the new entry. I fix it and save. The change is not "significant". (let's call the new version "v1.1") At work, the day after, I synchronize my APP client just as I do every morning. It does not notice the entry has changed because the atom:updated has not changed. (so, I'm still with v1.0, not v1.1 at this point). A bit later, I'm told to update the entry with some new information *and* go to a client's office: I'll edit the entry in the train (hopefully, I have a laptop!). In the train, I start to edit the entry. My APP client cannot connect to the server so it gives me v1.0 to edit.
From there, two possibilities:
- I know APP sucks, so I don't "save" the entry but copy it into a file. Once at work (or with a connection to the APP server), I'll use diff/patch tools to merge my update and the typo fixes, then only I'll "save" the entry. Until then, I can't be anything other than angry because of that extra work... - I don't know APP sucks, so, two possibilities: - I quickly add the new info into entry and save it. Later, at work, I'll synchronize my APP client with the server and the entry will be updated with some new content, but back with all these typos. I'll eventually notice the typos are back, I'll be angry: all that APP stuff really sucks! - During editing, I notice the typos are not fixed there, so I start fixing them again. I'm angry because of that extra work: all that APP stuff really sucks! Conclusion: no, synchronization is not covered. I once wrote a PaceOrderCollectionsByAppModified but it was reject. http://www.intertwingly.net/wiki/pie/PaceOrderCollectionsByAppModified I'd eventually be OK not to add that app:modified, but at least do not mandate that the feed is _ordered_ by atom:updated. How about saying that new entries and entries that have been "significantly" updated should appear at the beginning of the feed? This would at least not prevent a server to insert "insignificantly changed" entries in between. -- Thomas Broyer
