+1 for a Google group for Salmon. How about handling updates? At least intuitively, a delete is a special case of update -- what if someone updates their comment, how do we propagate that?
As far as existing examples go, FriendFeed is one of the few publishers that I'm aware of that actually distinguishes between new posts and updates: http://friendfeed.com/api/documentation#realtime Perhaps we could make the delete request as an update with empty body? ig On Oct 23, 6:20 pm, John Panzer <[email protected]> wrote: > My proposal would be: > 1. Support the existing Atom Tombstones spec extension > (http://ietfreport.isoc.org/all-ids/draft-snell-atompub-tombstones-06.txt) as > the 'official' way to indicate that a source has deleted something, if it > cares to tell downstream subscribers; > > 2. Add language that explains how the hub deals with the deleted-entry > brethren to real entries -- essentially, I think this should say that > they're treated just like atom:entry for purposes of deltas, atom:source, > etc. etc. so they get passed through. > > I think that's it. > > -- > John Panzer / Google > [email protected] / abstractioneer.org <http://www.abstractioneer.org/> / > @jpanzer > > On Fri, Oct 23, 2009 at 2:59 PM, Jeff Lindsay <[email protected]> wrote: > > 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 > >>>> athttp://salmon-playground.appspot.com/roswhichposts 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
