I apologize about the miscommunication. On twitter-api-announce (http://bit.ly/3UQ0LU) I posted the date of Monday (11/16), but unfortunately posted the wrong date on this group.
Sorry again for the confusion. On Nov 15, 10:40 am, Ryan Sarver <rsar...@twitter.com> wrote: > 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=1319042195162... > > >> >> 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!
