Is the cursor parameter usage explained anywhere? Can't find it on the
API doc site.
On Sep 8, 2009, at 2:10 PM, Alex Payne wrote:
It hasn't been deployed yet, but it's still gonna happen. Will update
when I know more.
On Tue, Sep 8, 2009 at 13:59, Yu-Shan Fung
wrote:
I remember read
It hasn't been deployed yet, but it's still gonna happen. Will update
when I know more.
On Tue, Sep 8, 2009 at 13:59, Yu-Shan Fung wrote:
> I remember reading about this a while back. Has this been deployed yet? The
> wiki doesn't look like it has any info about cursors.
> Thanks!
> Yu-Shan
>
>
>
I remember reading about this a while back. Has this been deployed yet? The
wiki doesn't look like it has any info about cursors.
Thanks!
Yu-Shan
On Tue, Aug 4, 2009 at 10:18 AM, Alex Payne wrote:
>
> Once we deprecate the page parameter, it will simply be ignored and
> the method will attempt
What about the XML response format? How will it change?
On 8/4/09 1:16 PM, Alex Payne wrote:
It will be a hash with 'ids' as one of the elements.
On Sat, Aug 1, 2009 at 18:26, Dewald Pretorius wrote:
Alex,
For non-paged calls, will the result set be [1,2,3,...] or will it be
{ids: [1,2,3
Chiming in: Please do support both methods of access for 'a while"
rather than a hard cutover... thx! At least two week would be
appreciated...
jeffrey greenberg
http://www.inventivity.com
http://www.tweettronics.com
On Aug 4, 10:15 am, Alex Payne wrote:
> What our infrastructure team has told
Once we deprecate the page parameter, it will simply be ignored and
the method will attempt to return the entire result set.
On Sun, Aug 2, 2009 at 15:15, janole wrote:
>
> Hi Alex,
>
>> In two weeks, we'll be addressing this with a change in back-end
>> infrastructure. The "page" parameter will
It will be a hash with 'ids' as one of the elements.
On Sat, Aug 1, 2009 at 18:26, Dewald Pretorius wrote:
>
> Alex,
>
> For non-paged calls, will the result set be [1,2,3,...] or will it be
> {ids: [1,2,3]} ?
>
> Dewald
>
> On Jul 31, 3:03 pm, Alex Payne wrote:
>> To clarify, since several peo
What our infrastructure team has told me is that they can support both
behaviors for a limited period of time.
On Fri, Jul 31, 2009 at 12:06, Isaiah wrote:
>
> First off, thanks for the heads up and giving us a large lead time. It's
> what I asked for in a previous email, and even if you never r
Graphs of more than several thousand users, following or followed by.
On Fri, Jul 31, 2009 at 11:09, Arik Fraimovich wrote:
>
>
>
> On Jul 31, 9:03 pm, Alex Payne wrote:
>> To clarify, since several people have asked: this pending change does
>> NOT mean that pagination is required. You can stil
Hi Alex,
> In two weeks, we'll be addressing this with a change in back-end
> infrastructure. The "page" parameter will be replaced with a "cursor"
does this mean the "page" parameter won't work anymore after the
change?
What's happening to those calls to the API still containing the
"page=x" p
Alex,
For non-paged calls, will the result set be [1,2,3,...] or will it be
{ids: [1,2,3]} ?
Dewald
On Jul 31, 3:03 pm, Alex Payne wrote:
> To clarify, since several people have asked: this pending change does
> NOT mean that pagination is required. You can still attempt to
> retrieve all IDs
Thanks for the notification.
What will this mean for etag checks?
I currently fetch a large number of graphs in regular intervals. Any
check that returns a 304 should incur little cost.
Will I need to crawl all the pages and check for their 304?
If I get a 304 on the first one, can I assume that
Thanks for the heads-up on this change! Good show.
On Jul 31, 3:06 pm, Isaiah wrote:
> First off, thanks for the heads up and giving us a large lead time.
> It's what I asked for in a previous email, and even if you never read
> that email and this isn't a response to me at all. I'll say t
First off, thanks for the heads up and giving us a large lead time.
It's what I asked for in a previous email, and even if you never read
that email and this isn't a response to me at all. I'll say thanks
anyway, because it's great. :-)
But, forgive me if I'm off base, but you're sayin
On Jul 31, 9:03 pm, Alex Payne wrote:
> To clarify, since several people have asked: this pending change does
> NOT mean that pagination is required. You can still attempt to
> retrieve all IDs in one call, but be aware that this is likely to time
> out or fail for users with large social graph
To clarify, since several people have asked: this pending change does
NOT mean that pagination is required. You can still attempt to
retrieve all IDs in one call, but be aware that this is likely to time
out or fail for users with large social graphs.
On Fri, Jul 31, 2009 at 10:35, Alex Payne wro
Alex, thanks for the advance notice, and having notification when you're at
the last page will be a huge improvement and help. Does this mean pagination
is now required for that method?
Jesse
On Fri, Jul 31, 2009 at 1:35 PM, Alex Payne wrote:
>
> The Twitter API currently has two methods for ret
17 matches
Mail list logo