Hmm. Seems like SSE tombstones are good enough for the use case I
illustrated; it's acceptable that clients who don't understand them
ignore them (they'll just see more spam), and the rest of the entry
isn't needed (it's spam, after all).
Are there any aggregators who implement this?
Cheers,
On 06/12/2007, at 4:45 AM, David Powell wrote:
Quoting James M Snell <[EMAIL PROTECTED]>:
http://www.snellspace.com/wp/?p=818
- James
1. Deleted entries (aka Tombstones) are indicated by extension
elements
contained within the atom:entry element. For clients that do not
understand
the SSE extensions, these will appear no different than any other
entry
such clients would have no way of knowing that the entry was
deleted. Also,
this solution assumes that there is still enough data in the
database to
reconstruct the deleted entry in the feed. The content, title,
tags, etc may
all have been removed from the database.
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.
I assumed that you aren't supposed to reconstruct those items, after
all you are trying to delete the item. The tombstone entry would look
something like this:
<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.
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.
Why create a new protocol when we can use an existing one?
--
Dave
--
Mark Nottingham http://www.mnot.net/
