Steven Lees wrote:
> This issue came up in the August AtomPub interop. Our current
> solution on http://feedsync.mslivelabs.com is that, by
> default, the server doesn't give you tombstoned entries. You
> have to ask for them with a query parameter. I've also been
> hunting for the right HTTP header to ask for tombstones as an
> alternate mechanism.
The most obvious way to do it would be to add a parameter to the
application/atom+xml mime type, and use that parameter along with a
strong "q" parameter in an Accept header:
Accept: application/atom+xml;type=feed;FeedSync=1.0;q=1,
application/atom+xml;q=0.9
I don't know what kind of politics are involved in that, though.
> I discussed that recently here:
> http://blogs.msdn.com/stevenlees/archive/2007/12/02/about-a-by
> .aspx. The short answer is that "by" is not really meant to
> be user readable. For that we'd recommend atom:author or
> something else in your data model.
Thanks for the link. I could have sworn that I had read that it was
intended to be user-readable. I guess as long as a (urn:uuid:) URI could
be used, there is no real problem.
> I wasn't so much referring to the conflict resolution part as
> the other sync metadata. Once piece that's really useful is
> the sx:sync/@updates attribute--it's simpler and more
> reliable than a timestamp for detecting updates. If you
> really only care about one-way (aka publish only) sync, then
> your FeedSync implementation becomes that much simpler.
Like James, I am not sure how much simpler it is for AtomPub. For other
feeds, I agree that it might be useful, but only if implementations are
more careful about updating it than they have been about updating
atom:updated.
Another question about FeedSync: In the FeedSync model, is it assumed
that the feed contains the complete, canonical representation of each
entry? See the thread "Indicate entry in Collection Feed is full
representation" on the atom-protocol mailing list:
http://www.imc.org/atom-protocol/mail-archive/msg10621.html
If so, then I think that most AtomPub implementations would require a
separate feed for FeedSync anyway (linked from the service document or
the collection feed using some new link relation), and the
backward-compatibility issue would not really be a factor.
- Brian
