On Dec 6, 2007 7:45 AM, David Powell <[EMAIL PROTECTED]> wrote:
> Quoting James M Snell <[EMAIL PROTECTED]>:
> > 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.
Agreed that putting the deleted entries in the same feed is problematic.
So why not put them in another feed? A feed dedicated to such
deleted entries, ala a trash/tombstone feed?
If I have feed that I want to keep track of deleted entries
for I could have a link to a trash/tombstone feed:
<feed ..>
<link rel="trash" href="http://example.org/trash/feed/";>
<entry>
...
</entry>
</feed>
And the feed at http://example.org/trash/feed/ would look like:
<feed ..>
<entry>
<id></id>
...
</entry>
....
</feed>
Now since atom:id does not change for an entry I need only trawl
through the entries
in the trash feed looking for atom:id's I've seen before. Require
that entries be ordered in reverse order by their app:edited value
and that trash feeds are chained together via link/@rel="next" links ala
AtomPub collections and you're all set. All that functionality
and the only thing you have to do is register a new link
relation of 'trash' or 'tombstone'. [Add the atom:link element with a
relation of "trash" to an AtomPub service document
collection as a way for collections to signal that they
support tombstones.]
-joe
--
Joe Gregorio http://bitworking.org
