I'm just thinking in a programming sense. If I built a blog tomorrow, I'd separate the feed generation stuff from the publishing logic. With a light ping, this works out fine since the feeds are generating on access (generation is deferred). With a fat ping, my blog now needs to generate the markup (whether Atom or RSS) for the current entry at the time of the ping (just after the publishing of content). In an ideal world, this costs little - programmers should have feed generators capable of reuse whenever needed. It's what I do at least, so for me, a fat ping would be a simple exercise.
In many cases though, it's not that simple and would require more work on behalf of publishers across a myriad of applications. That's a huge difference compared to the current light ping which a 6 year old could implement in a few lines in their sleep - which was kind of the intention of the specification as I read it. Make it practically a no brainer for Publishers and Subscribers, and leave the complexity with the Hubs. All I'm saying, without impinging on the overall benefit of a fat ping, is that from a programmer's perspective it's something we can't generically implement without also bundling a feed library to generate the ping. It would be up to individual applications over time to do so. The benefit of the light ping from that perspective is it's simple to just package it in a class and call it from practically anywhere with little work. Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com OpenID Europe Foundation Irish Representative ________________________________ From: todd hoff <[email protected]> To: Pubsubhubbub <[email protected]> Sent: Wed, January 27, 2010 4:29:30 PM Subject: [pubsubhubbub] Re: Possibility of fat ping from publisher to hub? On Jan 27, 4:20 am, Pádraic Brady <[email protected]> wrote: > Problem with a fat ping is that there's no guarantee a Publisher can access > the entire feed content at the time a ping is made. Often the ping is sent > after publishing new content, before and not necessarily after the new feed > has been generated (which can occur on the next user request, including the > Hub's). Could you please explain this a little more? You are saying the feed is virtual and only composed on access? How I've done this is before is a fat ping with an indication of how much data remains to be slurped up. If there is more data then the hub would return for more. Or the publisher can simply ping out data at a certain rate and the hub will never have to come back for more. > Pádraic Brady > > http://blog.astrumfutura.comhttp://www.survivethedeepend.com > OpenID Europe Foundation Irish Representative > > ________________________________ > From: todd hoff <[email protected]> > To: Pubsubhubbub <[email protected]> > Sent: Wed, January 27, 2010 5:22:26 AM > Subject: [pubsubhubbub] Possibility of fat ping from publisher to hub? > > My understanding is that there's a light ping from the publisher to > the hub. It would be convenient to use a fat ping here for the same > reason as a fat ping makes sense from the hub to the consumer. > Especially for low power devices the extra operations are a bit of a > drain.
