[twitter-dev] Re: UPDATE: Social Graph API Deprecation
Our application requires full social graph dump. One thing that I am not clear from the http://groups.google.com/group/twitter-api-announce/browse_thread/thread/a0ba66db0e86941d - is only pagination is depreciated or the use of cursors is made mandatory? Suppose if I want full social graph of followers - will the announcement affect it? Regards, Jagir On Jan 9, 1:29 am, Wilhelm Bierbaum wrote: > On December 22, 2009 we announced that the social graph method pagination of > the followers/ids and friends/ids would finally be removed. We announced > deprecation in September (http://bit.ly/46x1iL), November > (http://bit.ly/3UQ0LU) and December (http://bit.ly/5VPWk7) of last year. The > page parameter will be completely removed 1/11/2010. However, the behavior > of assuming that you want the first cursor page when passing no cursor > parameter will not. > > In the December 2009 announcement, I explained that: > > You should always pass a cursor parameter. Starting soon, if you fail to > pass a cursor, the data returned will be that of the first cursor (-1) and > the next_cursor and previous_cursor elements will be included. > > In response to the feedback we received in > ahttp://bit.ly/longDiscussionAboutTheSocialGraphwe have decided not to > immediately remove support for unreliably retrieving a complete friend or > follower list (by passing neither page nor cursor parameters) on 1/11/2010. > We understand that too many applications still depend on it. We're working > on a better way to pull this data; expect another updated announcement on > this list soon with further details. > > We know that the cursor-based social graph APIs can be improved -- we can > provide richer functionality than we currently expose. To do this, we need > your help; contribute your use cases for the social graph in response to > this message onhttp://bit.ly/TwitterDevelopmentTalk. With better > understanding of how you use the graph data, we can improve the quality and > variety of APIs that we provide. > > Thanks!
[twitter-dev] Re: UPDATE: Social Graph API Deprecation
I have two use cases: 1. Generating a list of all friends and followers. 2. Downloading the most recent 200 tweets of all friends and followers. The existing API functionality is adequate for the first. The second depends more on the rate limiting than the functionality. Right now, I have about 5000 contacts. At 150 calls per hour, this is over a day to complete. With the 1500 calls per hour I get with the coming oAuth boost, this will come down, but it's still going to be over an hour. On Jan 8, 12:29 pm, Wilhelm Bierbaum wrote: > On December 22, 2009 we announced that the social graph method pagination of > the followers/ids and friends/ids would finally be removed. We announced > deprecation in September (http://bit.ly/46x1iL), November > (http://bit.ly/3UQ0LU) and December (http://bit.ly/5VPWk7) of last year. The > page parameter will be completely removed 1/11/2010. However, the behavior > of assuming that you want the first cursor page when passing no cursor > parameter will not. > > In the December 2009 announcement, I explained that: > > You should always pass a cursor parameter. Starting soon, if you fail to > pass a cursor, the data returned will be that of the first cursor (-1) and > the next_cursor and previous_cursor elements will be included. > > In response to the feedback we received in > ahttp://bit.ly/longDiscussionAboutTheSocialGraphwe have decided not to > immediately remove support for unreliably retrieving a complete friend or > follower list (by passing neither page nor cursor parameters) on 1/11/2010. > We understand that too many applications still depend on it. We're working > on a better way to pull this data; expect another updated announcement on > this list soon with further details. > > We know that the cursor-based social graph APIs can be improved -- we can > provide richer functionality than we currently expose. To do this, we need > your help; contribute your use cases for the social graph in response to > this message onhttp://bit.ly/TwitterDevelopmentTalk. With better > understanding of how you use the graph data, we can improve the quality and > variety of APIs that we provide. > > Thanks!
[twitter-dev] Re: UPDATE: Social Graph API Deprecation
My use cases for the Social Graph API:
* Figure out mutual followers vs one-way followers, namely for my
Tweepsect application: http://tweepsect.com/
This requires a full graph dump, unless you include a parameter in the
statuses/{friends,followers} API calls that indicate whether said
friend is a mutual follower, or a just-friend (stalking) or a just-
follower (stalker). I need to load that data regardless, so if this is
included then I can omit loading the social graph altogether.
* For a Twitter client, for every tweet, figure out if the poster of
said tweet is a mutual follower or not.
Again, if this data was included under each tweet, I wouldn't need to
load the entire social graph.
* Crawling a user's social graph
If I could filter which results to get, such as by geolocation or by
mutualness or by when they last tweeted, it would reduce the amount of
work I have to do.
- shazow
On Jan 8, 12:29 pm, Wilhelm Bierbaum wrote:
> On December 22, 2009 we announced that the social graph method pagination of
> the followers/ids and friends/ids would finally be removed. We announced
> deprecation in September (http://bit.ly/46x1iL), November
> (http://bit.ly/3UQ0LU) and December (http://bit.ly/5VPWk7) of last year. The
> page parameter will be completely removed 1/11/2010. However, the behavior
> of assuming that you want the first cursor page when passing no cursor
> parameter will not.
>
> In the December 2009 announcement, I explained that:
>
> You should always pass a cursor parameter. Starting soon, if you fail to
> pass a cursor, the data returned will be that of the first cursor (-1) and
> the next_cursor and previous_cursor elements will be included.
>
> In response to the feedback we received in
> ahttp://bit.ly/longDiscussionAboutTheSocialGraphwe have decided not to
> immediately remove support for unreliably retrieving a complete friend or
> follower list (by passing neither page nor cursor parameters) on 1/11/2010.
> We understand that too many applications still depend on it. We're working
> on a better way to pull this data; expect another updated announcement on
> this list soon with further details.
>
> We know that the cursor-based social graph APIs can be improved -- we can
> provide richer functionality than we currently expose. To do this, we need
> your help; contribute your use cases for the social graph in response to
> this message onhttp://bit.ly/TwitterDevelopmentTalk. With better
> understanding of how you use the graph data, we can improve the quality and
> variety of APIs that we provide.
>
> Thanks!
