Dewald, We're already considering the possibilities around pushing Social Graph changes via the Streaming API. At this point it is very hard to guess if we'll ever offer this as a feature. I can't offer anything more concrete or useful, as this is just in the "Hey, what-if?" idea phase, and the issues, problems and priorities are far from clear.
In any case, the infrastructure isn't the difficult part and wouldn't require third parties. SGS changes are already serialized as JSON and moved around via Kestrel. Fanning out from SGS to a Hosebird queue for Streaming API syndication is how Hosebird already works. It practically writes itself. It would be a help to describe some compelling use cases for this data beyond efficiency, QoS and ease of use. -John Kalucki Services, Twitter Inc. On Jun 5, 6:08 am, dewald <dpr...@gmail.com> wrote: > New follower processing using the Social Graph methods will become a > bigger and bigger headache as more and more Twitter accounts grow into > the "must page" territory. > > I thought I'd put a completely different approach on the table and see > what everyone thinks about it. > > When doing new follower processing, one is not really interested in > the full follower list. You just want to know when a new follower > action happens on a Twitter account. > > To me, this sounds like a perfect candidate for a pub-sub > architecture. > > Instead of Twitter taking on that additional infrastructure load, I'd > recommend you investigate whether you can make new follower actions > available via Gnip.com. > > Gnip already has the ability to segment by people, tags and keywords, > so segmenting the transactions by Twitter screen name should fit into > their current architecture. > > It's a win for Twitter, because you push a new follower transaction > out once only to one single service, and you're done with it. Us > developers then grab those transactions from Gnip. It's a win for us > as well, because grabbing those transactions don't impact our site > rate limits. > > This pub-sub approach could work for a number of other developer needs > as well.
