I'd say many simply stick entries into a database/persistent store. They won't aggregate on the basis of cached feeds, simply because entries are not persistent in a feed document. So removal of an entry is an expected consequence of the non-persistent nature of feeds, and will not be interpreted as a deletion, and most likely will not see that entry removed from the aggregator (whether it be a desktop app or an online syndication planet-app).
The use-case you describe is entirely valid - but I'd say it's more of a niche strategy, better suited to feeds which are intended deliberately to reflect a specific state at any given time (probably not a blog then). If the feed were stateless, what would the point be? Paddy Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com OpenID Europe Foundation Irish Representative ________________________________ From: Matthew Terenzio <[email protected]> To: [email protected] Sent: Wed, October 7, 2009 3:59:27 PM Subject: [pubsubhubbub] Re: deleted an published entry scenario If an item in the feed is removed and you fetch it within the given window, it won't be there. If I store a cache of the feed on my server and update it when there is a change, the entry will no longer be on my server either. Surely there must be some aggregators that have worked like this, no? You are very much right that it is not the same as deletion and the life of an entry would be independent of the feed even if deletion were available in the spec because not everyone might support it or as you suggested, the entry might have moved downstream. But to say there is no use case for knowing the current state of the feed (if that is what you were saying) seems to be over-reaching even if it wouldn't help in this case. On Tue, Oct 6, 2009 at 12:16 PM, Bob Wyman <[email protected]> wrote: On Tue, Oct 6, 2009 at 9:20 AM, Niko Sams <[email protected]> wrote: >>> If PSHB doesn't support deletion, then I must >> fetch the original feed on every notification - >>> and ignore the supplied atom feed completely. >Why would you "fetch the original feed on every notification"? What >information would you get by doing that? >Atom provides no means to mark an item as deleted. Thus, reading the feed >won't tell you what is "deleted." > >I'm assuming that you realize that the mere removal of an item from a feed is >*not* the same as deletion. In this context, a "deletion" is really more like >a "retraction." The contents of a feed document are only a sliding window on >the virtual "feed" of all entries published to the feed over time. The >presence or absence of an entry in any particular feed document does not carry >information. The "life" of an entry is independent of its presence within any >particular feed document. > >What do you learn by fetching the original feed? (Note: The atom format spec >would say: "Nothing!") > >bob wyman > > > >On Tue, Oct 6, 2009 at 9:20 AM, Niko Sams <[email protected]> wrote: > > >>>>Hi, >> >> >>>>> Deletion in this kind of system is exceptionally difficult. This is why we >>>>> left any form of deletion out of the Atom spec itself. Please don't go >>>>> down >>>>> this path without a great deal of careful consideration... PSHB is getting >>>>> more and more complicated all the time. Do you really want to deal with >>>>> the >>>>> mess that will be created if folk think you're trying to handle >>>>> arbitrarily >>>>> complex distributed synchronization issues including deletions? >>If PSHB doesn't support deletion, then I must fetch the original feed >>>>on every >>>>notification - and ignore the supplied atom feed completely. >>>>Even if it is difficult - it is very important. >> >>>>Niko >> >
