Recently, we documented a new pagination mechanism for our "social graph" methods, /friends/ids and /followers/ids. Traditional page-based pagination doesn't dovetail with our recent backend changes, and we've now exposed a cursor-based pagination mechanism that's far more reliable.
Today, we've documented that this new pagination mechanism is also available for the /statuses/friends and /statuses/followers methods. With that change, we're setting a hard deprecation date for traditional pagination on these four methods: October 26th, 2009. That's over a month from now.
Once deprecated, we'll simply ignore the "page" parameter if it's sent by a client, and you'll get the default number of items for the method you're calling.
Is there any way that response times on the call could be improved?
It takes around 4 seconds to retrieve one cursor. When one retrieves
the followers/friends of an account with 100,000 of those, with 100
followers/friends per cursor, it takes more than an hour to retrieve
all the followers/friends.
It's not a train smash issue, it would just be good to have faster
response times. I have noticed the same slower response times
(measured against 0.4 seconds for other calls) on the social graph
methods when using cursors.
On Thu, Sep 24, 2009 at 19:07, Dewald Pretorius <dpr...@gmail.com> wrote:
> Alex,
> Thanks for this.
> Is there any way that response times on the call could be improved?
> It takes around 4 seconds to retrieve one cursor. When one retrieves > the followers/friends of an account with 100,000 of those, with 100 > followers/friends per cursor, it takes more than an hour to retrieve > all the followers/friends.
> It's not a train smash issue, it would just be good to have faster > response times. I have noticed the same slower response times > (measured against 0.4 seconds for other calls) on the social graph > methods when using cursors.
> Recently, we documented a new pagination mechanism for our "social
> graph" methods, /friends/ids and /followers/ids. Traditional
> page-based pagination doesn't dovetail with our recent backend
> changes, and we've now exposed acursor-based pagination mechanism
> that's far more reliable.
> Today, we've documented that this new pagination mechanism is also
> available for the /statuses/friends and /statuses/followers methods.
> With that change, we're setting a hard deprecation date for
> traditional pagination on these four methods: October 26th, 2009.
> That's over a month from now.
> Once deprecated, we'll simply ignore the "page" parameter if it's sent
> by a client, and you'll get the default number of items for the method
> you're calling.
> I've noticed a lot of failures on /statuses/user_timeline recently.
> Instead of thepageparameter, is it better to use max_id?
> --
> Kyle Mulkahttp://twilk.com- put your friends faces on your Twitter background
> On Sep 24, 8:47 pm, Alex Payne <a...@twitter.com> wrote:
> > Hi,
> > Recently, we documented a new pagination mechanism for our "social
> > graph" methods, /friends/ids and /followers/ids. Traditional
> >page-based pagination doesn't dovetail with our recent backend
> > changes, and we've now exposed acursor-based pagination mechanism
> > that's far more reliable.
> > Today, we've documented that this new pagination mechanism is also
> > available for the /statuses/friends and /statuses/followers methods.
> > With that change, we're setting a hard deprecation date for
> > traditional pagination on these four methods: October 26th, 2009.
> > That's over a month from now.
> > Once deprecated, we'll simply ignore the "page" parameter if it's sent
> > by a client, and you'll get the default number of items for the method
> > you're calling.
> > I've noticed a lot of failures on /statuses/user_timeline recently.
> > Instead of thepageparameter, is it better to use max_id?
> > --
> > Kyle Mulkahttp://twilk.com-put your friends faces on your Twitter background
> > On Sep 24, 8:47 pm, Alex Payne <a...@twitter.com> wrote:
> > > Hi,
> > > Recently, we documented a new pagination mechanism for our "social
> > > graph" methods, /friends/ids and /followers/ids. Traditional
> > >page-based pagination doesn't dovetail with our recent backend
> > > changes, and we've now exposed acursor-based pagination mechanism
> > > that's far more reliable.
> > > Today, we've documented that this new pagination mechanism is also
> > > available for the /statuses/friends and /statuses/followers methods.
> > > With that change, we're setting a hard deprecation date for
> > > traditional pagination on these four methods: October 26th, 2009.
> > > That's over a month from now.
> > > Once deprecated, we'll simply ignore the "page" parameter if it's sent
> > > by a client, and you'll get the default number of items for the method
> > > you're calling.
> > > On Sep 24, 8:47 pm, Alex Payne <a...@twitter.com> wrote:
> > > > Hi,
> > > > Recently, we documented a new pagination mechanism for our "social
> > > > graph" methods, /friends/ids and /followers/ids. Traditional
> > > >page-based pagination doesn't dovetail with our recent backend
> > > > changes, and we've now exposed acursor-based pagination mechanism
> > > > that's far more reliable.
> > > > Today, we've documented that this new pagination mechanism is also
> > > > available for the /statuses/friends and /statuses/followers methods.
> > > > With that change, we're setting a hard deprecation date for
> > > > traditional pagination on these four methods: October 26th, 2009.
> > > > That's over a month from now.
> > > > Once deprecated, we'll simply ignore the "page" parameter if it's sent
> > > > by a client, and you'll get the default number of items for the method
> > > > you're calling.
On Sat, Oct 24, 2009 at 6:49 PM, DustyReagan <dustyrea...@gmail.com> wrote:
> Bump.
> Anyone know if page deprecation still scheduled to happen on Oct. > 26th?
> On Oct 22, 3:17 am, Rich <rhyl...@gmail.com> wrote: > > I hope not, Apple are being especially slow at approving my update at > > the moment that includes the cursor changes!
> > On Oct 22, 3:20 am, DustyReagan <dustyrea...@gmail.com> wrote:
> > > Is page deprecation still scheduled to happen on Oct. 26th?
> > > Is this deprecation happening on all methods that have the cursor > > > parameter enabled?
> > > -Dusty
> > > On Oct 8, 5:26 am, Kyle Mulka <repalvigla...@yahoo.com> wrote:
> > > > I've noticed a lot of failures on /statuses/user_timeline recently. > > > > Instead of thepageparameter, is it better to use max_id?
> > > > -- > > > > Kyle Mulkahttp://twilk.com-putyour friends faces on your Twitter > background
> > > > On Sep 24, 8:47 pm, Alex Payne <a...@twitter.com> wrote:
> > > > > Hi,
> > > > > Recently, we documented a new pagination mechanism for our "social > > > > > graph" methods, /friends/ids and /followers/ids. Traditional > > > > >page-based pagination doesn't dovetail with our recent backend > > > > > changes, and we've now exposed acursor-based pagination mechanism > > > > > that's far more reliable.
> > > > > Today, we've documented that this new pagination mechanism is also > > > > > available for the /statuses/friends and /statuses/followers > methods. > > > > > With that change, we're setting a hard deprecation date for > > > > > traditional pagination on these four methods: October 26th, 2009. > > > > > That's over a month from now.
> > > > > Once deprecated, we'll simply ignore the "page" parameter if it's > sent > > > > > by a client, and you'll get the default number of items for the > method > > > > > you're calling.
> > > > > For more information, seehttp:// > apiwiki.twitter.com/Twitter-API-Documentation. Thanks.
Internal discussions indicate that removing the backing store that
supports this method remains a priority. The API will be disabled to
allow the backing store to be decommissioned.
> I guess they haven't indicated otherwise, so you'd have to presume it's
> still going to go ahead?
> I half expect they'll delay it due to performance issues raised, but I
> wouldn't bank on it.
> Tim.
> On Sat, Oct 24, 2009 at 6:49 PM, DustyReagan <dustyrea...@gmail.com> wrote:
> > Bump.
> > Anyone know if page deprecation still scheduled to happen on Oct.
> > 26th?
> > On Oct 22, 3:17 am, Rich <rhyl...@gmail.com> wrote:
> > > I hope not, Apple are being especially slow at approving my update at
> > > the moment that includes the cursor changes!
> > > On Oct 22, 3:20 am, DustyReagan <dustyrea...@gmail.com> wrote:
> > > > Is page deprecation still scheduled to happen on Oct. 26th?
> > > > Is this deprecation happening on all methods that have the cursor
> > > > parameter enabled?
> > > > -Dusty
> > > > On Oct 8, 5:26 am, Kyle Mulka <repalvigla...@yahoo.com> wrote:
> > > > > On Sep 24, 8:47 pm, Alex Payne <a...@twitter.com> wrote:
> > > > > > Hi,
> > > > > > Recently, we documented a new pagination mechanism for our "social
> > > > > > graph" methods, /friends/ids and /followers/ids. Traditional
> > > > > >page-based pagination doesn't dovetail with our recent backend
> > > > > > changes, and we've now exposed acursor-based pagination mechanism
> > > > > > that's far more reliable.
> > > > > > Today, we've documented that this new pagination mechanism is also
> > > > > > available for the /statuses/friends and /statuses/followers
> > methods.
> > > > > > With that change, we're setting a hard deprecation date for
> > > > > > traditional pagination on these four methods: October 26th, 2009.
> > > > > > That's over a month from now.
> > > > > > Once deprecated, we'll simply ignore the "page" parameter if it's
> > sent
> > > > > > by a client, and you'll get the default number of items for the
> > method
> > > > > > you're calling.
> > > > > > For more information, seehttp://
> > apiwiki.twitter.com/Twitter-API-Documentation. Thanks.
