Hi there, A few notes on the new cursor-based API.
Despite promises a month ago, it's not documented (except in an e-mail to this list) Rather than have the old, admittedly broken API return errors, you've elected to keep it up, corrupting databases everywhere. What was the thinking behind this? The new 'cursor', at least sometimes, is a 60 bit integer, which cannot be represented as an IEEE754 double, ie. the Javascript number type. Most/every JS implementation I know of will silently truncate this number. How does your API deal with that? It's questionable whether this should be used in its raw form for the JSON API. Can't you just quote it? Or more simply.. Presuming the 'cursor' is merely an encoded follower/friend ID used as a low key in an '>' index scan, why not just expose this directly as a parameter, rather than completely change the output format for an existing URL? What's going on with all the mystical encoding? And if it was for the 'prev_cursor' property, then what is the use of this? You cannot have prior knowledge without forward scanning from '-1' to discover these 'numbers' (or can you?), at which point you know all previous cursors anyway... Is it ever likely at some future date these endpoints will be capable of returning more than 39kb data per roundtrip (ie raw size of a 64bit int)? Some of us are charged for CPU time by the millisecond. David
