Updated version to fix a few typos in the original.... http://www.ietf.org/internet-drafts/draft-snell-http-prefer-01.txt
- James James M Snell wrote: > This could probably help: > > http://tools.ietf.org/html/draft-snell-http-prefer-00 > > Request: > ======== > GET /feed > Host: example.org > Prefer: feedsync-tombstones > > Response: > ========= > HTTP/1.1 200 OK > Vary: Prefer > > ... > > - James > > Joe Cheng wrote: >>> Now, Steven indicates that their implementation will not include the >>> tombstone by default. Clients that want tombstones would have to ask for >>> them explicitly. >> This doesn't belong in the implementation, it belongs in the spec. >> (Would this discussion even be taking place if opt-in had been in the >> spec from the start?) I have advocated HTTP headers for opt-in the >> past, but to avoid caching problems it seems like a link relation would >> be better. >> >> I like the idea of building tombstone-aware clients on top of client >> libraries that are not tombstone aware. The inline opt-in model seems >> like the easiest way of achieving that, to me. >> >> By the way, it's worth noting that while we're all still more or less >> talking about using tombstones in simple scenarios where AtomPub is >> already being used today, like keeping a feed reader store synchronized >> with a blog, Steven and his team is thinking of more ambitious >> scenarios, such as (but not limited to) multi-master replication with >> eventual consistency. >> >
