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 <rsar...@twitter.com> 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: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
