It may sound foolish, but some of us coded our apps a couple years
ago, improved them up to production readiness and then released and
moved on to something else. Each of these mayor changes would in
theory make one reread all this old code and find where one uses
whatever you plan to change this time.
I do not have that luxury of time. I strongly prefer to spend time
with my two kids than fix something that is not broken yet but
eventually will. I have recoded the whole app two times to accomodate,
and yes I am growing tired of playing this. My kids have not even
changed a single tooth and I have coded the whole app 3 times!!!
If it is soooo easy to change to oauth and streaming why don't you
release some open source code which implements the old calls using
these new capabilities? Then we would just point our old calls to our
own server.
It's called backwards compatibility.

And just like the previous two times, I do not plan to be absent from
my kids' life while I redo old code. I will just let it break and
*then* the failure points will be obvious. If it fixes in a day I
will. Else, end of life, and 80k users get a blog post.

And since users have no idea about this, I need an analogy...

Dear printing press users: the excessive amount of Bibles you have
been printing has created an undue demand of the L O R D letters. As
of today we will be supplying a very limited amount of these four
letters, but we will be supplying paper that has the word LORD
preprinted on it. Please adjust your texts accordingly.

On Feb 10, 3:43 pm, Ryan Sarver <> wrote:
> Beginning today, Twitter will no longer grant whitelisting requests.
> We will continue to allow whitelisting privileges for previously
> approved applications; however any unanswered requests recently
> submitted to Twitter will not be granted whitelist access.
> Twitter whitelisting was originally created as a way to allow
> developers to request large amounts of data through the REST API. It
> provided developers with an increase from 150 to 20,000 requests per
> hour, at a time when the API had few bulk request options and the
> Streaming API was not yet available.
> Since then, we've added new, more efficient tools for developers,
> including lookups, ID lists, authentication and the Streaming API.
> Instead of whitelisting, developers can use these tools to create
> applications and integrate with the Twitter platform.
> As always, we are committed to fostering an ecosystem that delivers
> value to Twitter users. Access to Twitter APIs scales as an
> application grows its userbase.  With authentication, an application
> can make 350 GET requests on a user’s behalf every hour. This means
> that for every user of your service, you can request their timelines,
> followers, friends, lists and saved searches up to 350 times per hour.
> Actions such as Tweeting, Favoriting, Retweeting and Following do not
> count towards this 350 limit. Using authentication on every request is
> recommended, so that you are not affected by other developers who
> share an IP address with you.
> We also want to acknowledge that there are going to be some things
> that developers want to do that just aren’t supported by the platform.
> Rather than granting additional privileges to accommodate those
> requests, we encourage developers to focus on what's possible within
> the rich variety of integration options already provided. Developers
> interested in elevated access to the Twitter stream for the purpose of
> research or analytics can contact our partner Gnip for more
> information.
> As always, we are here to answer questions, and help you build
> applications and services that offer value to users.
> Ryan
> --
> Ryan Sarver
> @rsarver

Twitter developer documentation and resources:
API updates via Twitter:
Issues/Enhancements Tracker:
Change your membership to this group:

Reply via email to