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.


Reply via email to