Also, apparently the 3200 users limit is no longer in effect for these methods.
I was able to successfully request and receive the 32nd 100 user block of @aplusk's followers! Kinda slow, took 168 seconds to retrieve 33 blocks of 100 users (slightly greater than 5 seconds per block; BTW, no retries were involved), but it did return a result that as near as I can tell, not being aplusK (Not that he ever looks at his followers anyhow :-) ), was correct. For grins, I tried to retrieve the 41st block, and gave up after ~45 minutes. So apparently, as previously noted in some discussion of caching somewhere in this group, it slows down considerably the deeper ya go into the list. (TIC: tongue in cheek): On the other hand, all those that have been whining about not being able to get screen names with the social graph methods now have a solution, albeit a slow one! And ya don't just get the screen names, ya get almost everything twitter knows about the user, including their current status! What more could you want! :-) Jim Renkel On Sep 29, 12:40 pm, "jim.renkel" <james.ren...@gmail.com> wrote: > In working with the new "cursorized" statuses/friends and statuses/ > followers methods, I noticed that in the block of users returned by > these methods that contain the last of the users following or followed > by the requesting user, the next_cursor value is "0". > > Is this a reliable, guaranteed indicator of the last block of users, > that there's no point in going further 'cause there ain't no further? > > If so, will the value always be exactly "0" (although without the > quotes in the responses, i.e., is a string comparison for "0" safe, or > could it be "000", say, in which case a conversion to numeric and a > numeric comparison for 0 would be necessary. I would certainly like it > to be the former! > > Either way, string or numeric, if this is a reliable indicator of the > last block of users, the documentation should be updated to reflect > this. > > Thanks in advance. > > Jim Renkel
