(A discussion group for Salmon is on my to-do list -- will bump priority up.)
In the case of PubSubHubbub, if you assume fidelity of GUIDs (atom:id) then updates become nearly trivial -- you key off of the GUID and replace the old version with the new version (or append a revision, or whatever strikes your fancy). So yes, an update with an empty content, title, and summary would be almost like a delete -- but that would also be an invalid atom:entry :(. I believe issues like this are what drove the deleted-entry mechanism. -- John Panzer / Google [email protected] / abstractioneer.org <http://www.abstractioneer.org/> / @jpanzer On Sat, Oct 24, 2009 at 7:59 AM, igrigorik <[email protected]> wrote: > > +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 >
