I want to believe! If there are compelling arguments, we'll consider
this deeply. So far I'm still unconvinced.

The Streaming API is built only on open standards: HTTP, XML, JSON.
Anyone can build a Streaming API client in a few hours of work using
well worn libraries and techniques. (Only a slight abuse of the HTTP
protocol is required.)

FWIW: In this current DDoS, publishing to hubs probably would have
fallen behind or ran out of content anyway. The redundancy required to
ride out the DDoS for either the Streaming API or publishing are
similar, if not the same. It's not an altogether compelling argument.

Moving to PubHubSubBub seems like reinventing the Streaming API wheel.
This argument cuts both ways.

The most convincing arguments would be those supporting a broad use
case that we currently cannot support via the existing Twitter APIs.


On Aug 9, 10:00 am, Jesse Stay <jesses...@gmail.com> wrote:
> Just so I'm clear, my suggestion on PubSubHubbub isn't meant to be a
> complaint. I'm hoping it at least starts a worthy and constructive
> discussion on standards-based real time distribution.  I'm hoping I'm being
> constructive here - I'd like to see Twitter survive the next DDoS, and I'd
> also like to see it much easier for developers to embrace Twitter as a
> "utility" or "the pulse of the internet" (as TechCrunch puts it).  For that
> to happen, basing on open standards (or opening your own for other groups to
> embrace in their own environments) is the only way that will happen.  There
> are already great ways of doing this, so why re-invent the wheel when you
> could be contributing to a great cause that already exists?
>
> Jesse
>
> On Sun, Aug 9, 2009 at 12:53 PM, Nick Arnett <nick.arn...@gmail.com> wrote:
>
> > On Sat, Aug 8, 2009 at 9:06 PM, Jesse Stay <jesses...@gmail.com> 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:
>
> >>http://code.google.com/p/pubsubhubbub/
>
> >> 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.
>
> > Couldn't app developers do this on their own, by allowing the user to
> > configure "Also publish to pubsubhubhub server" in the app?  There's a
> > potential revenue stream there for developers - charge a small fee for this
> > use of the server. That would make the system even more robust, since their
> > would still be a publishing path even if Twitter were completely down.
>
> > Seems to me that there are good reasons for both to exist... and I don't
> > see why Twitter needs to take the lead on this.  Current Twitter apps are
> > sort of like email clients that can only talk to one brand of mail server.
>
> > To put this another way, I think app developers need to start thinking of
> > it the way they really are using it - as infrastructure.  Complaining about
> > the current problem is a bit like a mechanic complaining that an auto parts
> > store doesn't have a particular part when there are ten other stores that
> > have it in stock.
>
> > Nick

Reply via email to