Brian Smith wrote:
> 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
Thanks, seems like a good suggestion. Presumably the client could specify:
Accept: application/atom+xml;type=feed;FeedSync=1.0;q=1
if it only wants the feed with tombstones. And then on the return trip, the
server uses the same Content-Type:
Content-Type: application/atom+xml;type=feed;FeedSync=1.0
One potential drawback is that in both cases, the entity returned is actually a
valid Atom feed. It might be nice to have the "tombstone-ness" reflected in a
way that doesn't alter the Content-Type.
>
> > 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.
You're probably not mistaken, the reason that I wrote up the post was that we
haven't been very clear with "by". In the past we've often used values that
look temptingly user-readable. Any kind of URI is perfectly reasonable to use
for by, including urn:uuid.
> > 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.
You're absolutely right that for sync to work, clients must always correctly
update the "updates" attribute. That's what makes the whole thing work.
Luckily, it's pretty simple to do, even for someone hand editing the feed. It's
a lot harder to generate the UUID by hand. :-)
> 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
FeedSync is no different from plain Atom in this regard. The data that you want
to synchronize needs to be in the feed; whether that's partial data or complete
is up to the implementer. It's perfectly reasonable to have a separate feed for
sync, but our goal is to design the system so that's not at all a requirement.
Steven
