We're adding strings in addition to the numeric representation. See
the announcement at 
http://groups.google.com/group/twitter-api-announce/browse_frm/thread/67bacbc45a922b38.

On Dec 22, 5:21 pm, Josh Roesslein <[email protected]> wrote:
> I wonder if in the next API version you could just make next_cusor and
> previous_cursor strings. Is there really a use case
> for having to return them as JSON ints? Most of the time they get
> converted to strings and appended onto the API requests.
>
> Josh
>
>
>
> On Tue, Dec 22, 2009 at 6:54 PM, Wilhelm Bierbaum <[email protected]> wrote:
> > Sorry, I had a typo in one of the examples.
> > The second example (with additions) should read:
> >     {
> >     "users":[{<!-- ... omitted records ... -->}}, ...],
> >     "next_cursor":319261365477361289,
> >     "next_cursor_str":"319261365477361289",
> >     "previous_cursor":0,
> >     "previous_cursor_str":"0"
> >     }
> > instead of
> >     {
> >     "users":[{<!-- ... omitted records ... -->}}, ...],
> >     "next_cursor":319261365477361289,
> >     "next_cursor_str":"319261365477361289",
> >     "previous_cursor":0,
> >     "previous_cursor":"0"
> >     }
>
> > Revised post follows...
> > ----------------------------------
> > In response to complaints we've been receiving aboutcursorIDs being
> > difficult to deal with because of their length (for example,
> > JavaScript can't deal with them -- seehttp://bit.ly/cursooooors),
> > we're adding string equivalents of next_cursor and previouscursorto
> > those methods that return cursors when the JSON format is used.
> > A detailed account of the problems with big numbers and JavaScript
> > can be found athttp://bit.ly/tooManyNumbers.
> > If you strictly parse your top-level returned JSON (which seems
> > unlikely given the spirit of the standard), you may need to make
> > some adjustments to your code.
> > Where the JSON withcursorparameters used to look like
> >     {
> >     "users":[{<!-- ... omitted records ... -->}}, ...],
> >     "next_cursor":319261365477361289,
> >     "previous_cursor":0
> >     }
> > it will now return equivalent string values for next_cursor and
> > previous_cursor called next_cursor_str and previous_cursor_str,
> > respectively:
> >     {
> >     "users":[{<!-- ... omitted records ... -->}}, ...],
> >     "next_cursor":319261365477361289,
> >     "next_cursor_str":"319261365477361289",
> >     "previous_cursor":0,
> >     "previous_cursor_str":"0"
> >     }
>
> > We hope this helps out those of you who were previously experiencing
> > trouble with cursors.
> > If you have any questions or comments, please feel free to post them
> > to twitter-development-talk.
> > Thanks!
> > --
> > Wilhelm Bierbaum
> > Twitter Platform Team

Reply via email to