David Powell
> I disagree. Having clients that don't understand the
> extensions processing them in the same way as updates to the
> entries seems like a massive plus-point for FeedSync to me.
<snip>
> <entry>
> <id>id of the original entry</id>
> <updated>deletion date</updated>
> <sx:deleted />
> <title>This entry has been removed</title>
> <summary>This entry has been removed</summary>
> ...
> </entry>
>
> If the client supports sx:deleted it can remove the entry
> from its store, if the client doesn't support sx:deleted, it
> will replace the old entry with this low-tech tombstone. If
> the client is a framework, sub-clients will have the
> opportunity to implement sx:deleted, even if the framework
> doesn't. A publishing client that understands sx:deleted
> could delete an entry in this way on any arbitrary atompub
> server. There is very little coordination cost - you can use
> it today and wait for the rest of the infrastructure to catch
> up.
You make a good point. But, if there are frequent deletions then
non-FeedSync-aware clients will have to wade through "This entry has
been removed" entries showing up to replace entries that they have
previously marked as read or otherwise filed as "don't show me this
again unless it is updated".
Consider this alternative formulation:
<entry>
<id>id of the original entry</id>
<updated>deletion date</updated>
<title>This entry has been removed</title>
<summary>This entry has been removed</summary>
...
</entry>
<sx:deleted>
<atom:id>id of the original entry</atom:id>
</sx:deleted>
This accomplishes your goal, but makes the "low tech tombstone"
optional, for cases where asking clients to navigate "This entry has
been removed" entries is inappropriate. It does require the server to
insert <xs:deleted>, though.
> The feed + stream of entries model is the 'protocol' of how
> feeds work. FeedSync is backwards compatible with this
> protocol; your alternate proposal seems to require a
> boil-the-ocean from publishing clients, atompub servers,
> intermediaries, feed servers, aggregator frameworks, and
> aggregators before these tombstones will work.
The FeedSync mechanism is reasonable if only a few entries are
occasionally deleted. But, it is not reasonable in other situations. In
particular, in WLW I save all my drafts on the server and often delete
drafts without publishing them. I don't want to see a bunch of tombstone
entries in the article list. The Snell mechanism would be more
appropriate in that scenario.
- Brian
