It's not. I'm wondering what kind of behavior they expect from this kind of feature in the protocol. If it's just a way to notify subscribers a feed item was deleted and they deal with that however they like, that seems like it would be much easier to get into the spec. Are they any AtomPub-like semantics for this sort of thing?
My experience with this project so far is that if you want to get something like this in the spec and there is general consensus it's a good idea, you can write up a proposal of what can go in the spec and then Brett and/or Brad will work on integrating it. -jeff On Fri, Oct 23, 2009 at 2:52 PM, Jeff Eddings <[email protected]> wrote: > 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 >>> >>> >> > -- Jeff Lindsay http://webhooks.org -- Make the web more programmable http://shdh.org -- A party for hackers and thinkers http://tigdb.com -- Discover indie games http://progrium.com -- More interesting things
