Just to clarify, the Hub's update at the end could use the custom element Brett mentioned. It would be a simple matter to detect before offloading any processing to a feed parser. A nice extensible parser would make it doubly easy ;).
Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com OpenID Europe Foundation Irish Representative ________________________________ From: Pádraic Brady <[email protected]> To: [email protected] Sent: Wed, October 7, 2009 12:25:54 PM Subject: [pubsubhubbub] Re: deleted an published entry scenario Bob is quite right - removing an entry from a feed means absolutely nothing and should not be considered a "deletion". If that were the case, last week I deleted 7 blog entries (I didn't - I cut down on the entry count in my feeds because they were stressing the local server for some reason). To support deletion, you're stuck with two big problems. 1. Blogs don't support it out of the box, and it would likely need some pretty drastic fundamental changes in how feeds operate. 2. Aggregators don't support it either. Many detect changes based on either IDs, or using a content hash they generate to detect content changes (somewhat required due to fuzziness in how RSS is implemented from publisher to publisher). These are problems because most PuSH implementations will (or should) delegate feed processing to existing solutions and libraries for parsing/collating entries. Some libraries will go so far as to normalise RSS and Atom to a single information format (within reason, and not necessarily on a file basis - a simple API goes a long long way I've found). Nevertheless, nothing really says Pubsubhubbub is restricted to any single format per se. Yes, Atom and RSS are the backbone of adoption but I've already seen a few threads contemplating other use cases for other documents. So perhaps, as an extension possibly, deletion could be supported as a partner transaction to how publishing is notified to Hubs? The feeds would remain unchanged in that case. Paddy Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com OpenID Europe Foundation Irish Representative ________________________________ From: Niko Sams <[email protected]> To: Pubsubhubbub <[email protected]> Sent: Wed, October 7, 2009 7:35:21 AM Subject: [pubsubhubbub] Re: deleted an published entry scenario On 6 Okt., 18:16, 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!") I see your point, thanks for the clearification. Still it's a practical use case that a blog entry get's removed. Niko
