I just wanted to add some additional color to this as it didn't come through well in our email announcement. The actual change is happening Monday morning. Our email unfortunately said "today" as we were planning to send it the day of, but we ended up sending it earlier to give more notice and forgot to update the language.
To your point, our team specifically choose Monday morning so people wouldn't have to be working on the weekend to fix things. We definitely have heard everyone in the past and are trying to ensure that all future changes like this happen early in the week and early in the day. Sorry again for the confusion, but we are listening and learning :) thanks for your patience and hard work and hope everyone is having a good weekend. Best, Ryan On Fri, Nov 13, 2009 at 10:45 PM, Tim Haines <tmhai...@gmail.com> wrote: > Just like everyone knew the twitpocalypse was coming - but people still got > burnt - even some high profile apps. An earlier day in the week is prudent > if it's a planned change. > > On Sat, Nov 14, 2009 at 7:14 PM, Josh Roesslein <jroessl...@gmail.com> > wrote: >> >> Well I think most issues should have been long resolved by now. >> Cursors have been live for a while now >> and there was plenty of warning ahead of today. The turn off should >> have no affect if you have ported to Cursors. >> >> On Fri, Nov 13, 2009 at 11:25 PM, Naveen Ayyagari <knig...@gmail.com> >> wrote: >> > I agree, friday is a poor time to make planned changes to the API... >> > >> > On Nov 13, 2009, at 11:58 PM, Jesse Stay wrote: >> > >> > I've already implemented this, but for future sanity, can you guys avoid >> > doing these major updates on Fridays when we're all not focusing as much >> > on >> > work? That way if there happen to be any bugs or problems our weekends >> > aren't ruined. This seems to be a frequent occurrence on the Twitter >> > API. >> > Thanks, >> > Jesse >> > >> > On Fri, Nov 13, 2009 at 3:03 PM, Wilhelm Bierbaum <wilh...@twitter.com> >> > wrote: >> >> >> >> As previously announced by Alex Payne on September 24th (see >> >> http://bit.ly/46x1iL), we're removing support for pagination from the / >> >> friends/ids and /followers/ids methods. >> >> >> >> As of that time we set a hard deadline of October 26th, 2009. The >> >> original date has passed as we tried to give all of our partners extra >> >> time, but we are going to need to make the change now. >> >> >> >> At some point today, the "page" and "count" parameters will be ignored >> >> by the /friends/ids and /followers/ids methods and we will only be >> >> supporting cursors. >> >> >> >> Unfortunately, due to architectural considerations, cursor identifiers >> >> are not predictable. This means that you will have to extract the next >> >> and previous cursor identifiers from the results returned to you. >> >> >> >> For example, to get Obama's followers, we would first perform a GET >> >> against: >> >> http://twitter.com/followers/ids/barackobama.xml?cursor=-1 >> >> >> >> Which returns XML similar to: >> >> <id_list> >> >> <ids> >> >> <id>30592818</id> >> >> (... more ids ...) >> >> </ids> >> >> <next_cursor>1319042195162293654</next_cursor> >> >> <previous_cursor>-8675309</previous_cursor> >> >> </id_list> >> >> >> >> To retrieve the next 5000 IDs, we would then perform a GET against: >> >> >> >> >> >> http://twitter.com/followers/ids/barackobama.xml?cursor=1319042195162293654 >> >> >> >> Note that cursors are signed 64-bit integers. >> >> >> >> Please refer to the documentation for our social graph methods for >> >> more information: >> >> http://apiwiki.twitter.com/Twitter-REST-API-Method:-friends+ids >> >> http://apiwiki.twitter.com/Twitter-REST-API-Method:-followers+ids >> >> >> >> Thanks! >> > >> > >> > > >
