In short, it actually *is* more efficient to send fat pings. There are less requests, cpu cycles, and transfer in total in the end. However, I don't even care about that. It's just super convenient to HAVE the data when the code triggered from the event of an update. And in practice (because I've been using and watching this model for a long time, more generally known as webhooks), it can really suck to not know what changed when you get the ping. If you pass the relevant data on the event, there is no question, and it's right there, AND it happens to be more efficient in the end all things considered.
Although it seems like this breaks things like caching, you can still do your own caching as the subscriber -- just not HTTP level caching. But really, if you think about it, it doesn't really make sense to cache because you're always dealing with content updates. There is also a very intentional decision to make both ends as simple as possible, and making the subscriber queue and fetch and diff is really pushing a lot of the complexity and work off to them ... when there is really no need to. Hopefully that mostly or generally answers your question! -jeff On Mon, Oct 26, 2009 at 9:32 AM, Brett Slatkin <[email protected]> wrote: > > PubSubHubbub has two legs: 1) a light ping from publisher to the hub, > 2) a fat ping (or content push) from the hub to the subscriber. > > Alexis is referring to #1 not being fat. The story thus far has been > if a publisher wants to fat ping, they should integrate a Hub into > their CMS. > > Otherwise, the benefits of fat content pushing versus URL forwarding > is discussed in some detail here: > > http://code.google.com/p/pubsubhubbub/wiki/ComparingProtocols > > On Mon, Oct 26, 2009 at 9:29 AM, Alexis Richardson > <[email protected]> wrote: > > > > Alex > > > > PSHB is not using fat pings. There are use cases for fat pings that > > are under discussion, but fat pings are not in the spec at this time. > > > > alexis > > > > > > On Mon, Oct 26, 2009 at 4:12 PM, Alex Barth <[email protected]> wrote: > >> > >> I am *very* excited about the pubsubhubbub work I'm seeing. I consider > >> making it a mainstay of our aggregation infrastructure. > >> > >> Reading the spec and some of the issues on project page, my main > >> question is: > >> > >> Why does PuSH POST the entire feed to subscribers? > >> > >> To me it would seem more efficient that the hub exposes the updated > >> feed on a URL and then POSTs only this URL to the subscribers. The > >> subscribers would then GET the feed from the hub. > >> > >> The amount of data to be posted would be a fraction, the updated feed > >> hosted by the hub could be cached with a reverse proxy like Varnish or > >> Squid. Subscribers could queue URLs neatly, then work them off > >> asynchronously. > >> > >> Further, allowing POSTing a URL where updated data can be fetched > >> would open Pubsubhubbub to be applied in fields where the data feeds > >> are large (look at http://data.gov). > >> > >> What are the reasons behind the design decision on PuSH posting fat > >> pings? Is there an option to post light pings that I am overlooking? > >> Are there threads I should be reading up? > >> > >> Alex > >> > >> -- > >> I'm one of the geeks at http://developmentseed.org and as such I do a > >> lot of work with aggregation for news tracking and Open Data in > >> Drupal. Recently we launched an open source news tracker called > >> Managing News http://managingnews.com. I maintain and have helped > >> maintain 3 aggregators for Drupal (e. g. > http://drupal.org/project/feedapi > >> and its reincarnation: http://drupal.org/project/feeds). > >> > > > -- 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
