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 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 >
