I've looked into PubSubHubHub, as have others at Twitter. It's not on
our roadmap, because the Streaming API meets most of our developers'
real-time and push needs. There are holes, to be sure, and we have
features on the roadmap to plug those holes as priority and schedules
permit. But, we've proven the platform at modest scale, and believe
that it will scale up significantly with little additional effort.

There also may be some interesting scaling issues with a Request-
Response push mechanism that are avoided with a streaming approach.
We'd need quite a farm of threads to have sufficient outbound
throughput against the RTT latency of an HTTP post. I would have to
assume that nearly all high-volume updaters and most mid-volume
updaters would be pushed to a non-trivial number of hubs. Tractable,
but it would require some effort, especially to deal with unreliable
and slow hubs.

If you are looking at RSS feeds, I'd guess that you are looking at
grabbing user timelines. The Streaming API already supports this via
the /follow resource. If this doesn't meet your needs, email me with
your requirements and we'll see how we can support your use case.

-John Kalucki
Services, Twitter Inc.

On Aug 8, 9:06 pm, Jesse Stay <> wrote:
> I know Twitter has bigger priorities, so if you can put this on your "to
> think about" list for after the DDoS problems are taken care of, I'd
> appreciate it.  Perhaps this question is for John since it has to do with
> real-time.  Anyway, is there any plan to support the PubSubHubbub protocol
> with Twitter's RSS feeds for users?  I think that could be a great
> alternative to Twitter real-time that's standards compliant and open.  It
> would also make things really easy for me for a project I'm working on.
>  Here's the standard in case anyone needs a refresher:
> You guys would rule if you supported this.  It would probably take a bit
> less strain on what you're doing now as well for real-time feeds.  It could
> also reduce repeated polling on RSS.
> Jesse

Reply via email to