In talking with Flickr today, deleting items from a feed seems to be a must-have for them for implementing PuSH. It sounds like it isn't in the spec (yet). Being more of a interested observer rather than a dedicated contributor, how do we get such a feature into the spec?
Thanks, Jeff On Fri, Oct 23, 2009 at 12:40 PM, John Panzer <[email protected]> wrote: > Yes, that makes sense -- most of these issues are generic. > > One other one which I just remembered: How to deal with deletion of > entries. Specifically, I want to be able to push a deletion upstream, and > then broadcast it out, the same way that a new or changed comment is pushed. > In practice this probably means adopting one of the tombstone specs, e.g., > http://ietfreport.isoc.org/all-ids/draft-snell-atompub-tombstones-06.txt. > This in turn would require that the hub understand some semantics about the > deleted-entry element (a child of feed), as opposed to the entry element, > which is all the current spec talks about. Thoughts? > > (This is actually fairly important for spam control in the case of Salmon > -- if a comment is published and pushed via PubSubHubbub, but subsequently > discovered to be spam, we need a claw-back mechanism. It doesn't have to be > honored by downstream subscribers of course, but they should have the > opportunity to be informed. It's not always possible to filter spam before > publishing, especially when you're trying to be real time.) > > -- > John Panzer / Google > [email protected] / abstractioneer.org <http://www.abstractioneer.org/> / > @jpanzer > > > > On Fri, Oct 23, 2009 at 12:18 PM, Pádraic Brady > <[email protected]>wrote: > >> I started watching the Salmon Protocol (you guys need a mailing list!) a >> while back when I noticed a few posts about it on Twitter. >> >> In relation to the issues you raised, subscriptions can be given a limited >> time to live, but the issue is in who defines the TTL - some Hubs may assume >> unlimited TTLs for all subscriptions so it can become important to make sure >> Subscribers are passing a realistic lease_seconds value. I'm not sure that >> Hubs can manage this any other way, other than to periodically purge >> inactive feeds through some garbage collection tasks - such a task is >> undefined in the specification but maybe automatic re-subscriptions will >> ease in the behaviour most suitable for comment feeds. It still needs >> Subscriber support for the most part in being intelligent about their lease >> period. >> >> It's really a very messy area. Can Hubs filter subscriptions? Eliminate >> subscriptions to feeds without updates within X months, etc? As someone on >> another topic noted, Subscribers do need to pay attention to their >> subscriptions and manage them. I think this is a good practice so Hubs are >> not unduly burdened with tracking subscriptions to dead or inactive feeds, >> or feeds with a limited useful lifetime (in terms of activity not content). >> >> On Hubs changing the source feed - most probably won't. It costs little to >> maintain an entry as-is for distribution. Some Hubs may basically condense >> the feed changes to a narrow spectrum of elements - removing the rest. It's >> not really specified so it's up to Publishers to select appropriate Hubs. >> You also can't rely on Subscribers tracking the different behaviour of >> individual Hubs. The PHP Hub I'm writing at the moment won't perform any >> filtering since doing so potentially robs feeds of information that looks >> unnecessary in one use case, but becomes essential in another (e.g. Salmon). >> >> Paddy >> >> Pádraic Brady >> >> http://blog.astrumfutura.com >> http://www.survivethedeepend.com >> OpenID Europe Foundation Irish Representative<http://www.openideurope.eu/> >> >> >> ------------------------------ >> *From:* John Panzer <[email protected]> >> *To:* [email protected] >> *Sent:* Fri, October 23, 2009 7:30:34 PM >> *Subject:* [pubsubhubbub] Salmon Protocol >> >> The Salmon Protocol (http://salmon-protocol.org) leverages PubSubHubbub >> and web hooks to build a real time, decentralized commenting and annotation >> system. The basic idea is that commentary swims upstream to the thing being >> commented on, which can then redistribute comments back out via PubSubHubbub >> to interested subscribers. >> >> There's a demo available at http://salmon-playground.appspot.com/roswhich >> posts comments back to a Blogger blog (by proxying to an existing API, >> just for demo purposes). >> >> Aside from evangelizing Salmon, I'm also interested in getting feedback on >> the use of PubSubHubbub. One specific question: At the moment, Salmon >> specifies that subscribers should follow the rel="comment" link for each >> entry in an Atom feed to find the comment feed to subscribe to. This could >> lead to a lot of subscriptions that have initial activity but then die out; >> not sure if this is a problem for PubSubHubbub or not. It might be better >> to define a feed for, and there fore a way to subscribe to, "all comments >> for items in this feed" as a whole -- but there's no standard way to do this >> at the moment. >> >> Also, Salmon definitely needs some extensions to get passed through >> un-modified (like crosspost:source, thr:in-reply-to, etc.) so the discussion >> about what hubs may/may not change is very relevant. >> >> Comments, critiques, feedback of all kinds welcomed. >> >> -- >> John Panzer / Google >> [email protected] / abstractioneer.org <http://www.abstractioneer.org/>/ >> @jpanzer >> >> >
