Steven Lees wrote: > Brian Smith wrote: > > 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.
I would expect the presence of the FeedSync parameter to enable the whole FeedSync mechanism, and the absence of the mechanism to indicate that none of the FeedSync mechanism is wanted. > 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. Clients already have to deal with the optional "type" parameter for the Atom mime type, and if they are using the parameter in the request, then they should be able to handle it in the response. Further, a FeedSync-enabled server might require that clients provide the parameter the Content-Type of PUT and POST requests, so that the client can indicate that it follows the FeedSync specification. > 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. :-) Every time I open my feed reader, I find at least one feed where all entries appear updated "today" because the author upgraded to a new version of WordPress or changed their template or some other thing. The vast majority of my feeds are authored and admined by top-tier programmers, and yet these kinds of problems still happen all the time. To me, this is a good indication that the updates attribute is likely to not be handled properly either. > 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. Note that this is the opposite of AtomPub; see section 10 of RFC 5023. In particular, the entries in an AtomPub collection feed are likely to be only summaries of the actual entries. That is why I think that a FeedSync feed is likely to be separate from the normal collection feed (either difference URIs or by using the Accept header or something). - Brian
