Hey Jeff, Thanks for the follow-up.
On Thu, Feb 24, 2011 at 11:49 PM, Jeff Lindsay <[email protected]> wrote: > JSON (or arbitrary payloads) and "fat pings". The point of my remark > is that as long as feeds are a first-class citizen of PubSubHubbub, it > will remain within the limited subset of people interested in both > feeds and realtime/webhooks -- which *is* limited because most people > interested in feeds are fine with feeds as they are, and those > interested in webhooks don't want anything to do with feeds. > > I've heard of a lot of people turn to PubSubHubbub looking for > something to help with webhooks, and then end up ignoring it or using > pieces of it, a la Facebook and Instagram (and GitHub is considering > doing the same). This is also the reason I started losing interest in > it -- feeds have nothing to do with the problem I wanted it to solve. I believe that for GitHub's case; that's what they've said in various discussions. Let's call them the "pure" webhooks case. However, when I look at Facebook and Instagram's APIs, what I see are common Feed-like idioms being reinvented. For example, Instagram is using time since epoch as the date string (not ISO, etc). They both also side-step idempotent event ordering by using a combination of semi-fat ping/client re-fetch. To your point: I agree that that the surface area of a JSON-oriented or arbitrary payload PubSubHubbub spec would need to be smaller. None of the weight of Atom and RSS besides what it absolutely essential; that's the part people throw out, like you're saying. I think Superfeedr's arbitrary content support is a good starting point (http://blog.superfeedr.com/arbitrary-content-pubsubhubbub/). What do you think? > I'd love to talk about this at the next Evented Web meetup next month. > You're all invited. My remark was partly inspired by Instagram, and > partly from the discussion at tonight's meeting. Sounds good. Do you have a link for more info about the next one? -Bret
