Why is the API not versioned then? api.twitter.com/?v=1,
api.twitter.com/?v=1.1, api.twitter.com/?v=1.2 etc
Or, if that is too much maintenance, how about
api.twitter.com/?bitfix=32 or whatever.
--
Scott * If you contact me off list replace talklists@ with scott@ *
On Sep 25, 2009, at 6:40 PM, JDG wrote:
and it would also break everyone who CAN handle 64 bit ints and
expects
results in decimal numeric format.
On Fri, Sep 25, 2009 at 16:01, Richard <ryt...@gmail.com> wrote:
Can this not be returned as hex or base64?
It would save bandwidth for Twitter (and us) and make it a string
people could convert it to 64bit int if they still want to.
On Sep 25, 10:16 pm, Scott Haneda <talkli...@newgeo.com> wrote:
I would not change either. But there are those here that are
stating
they need new hardware to work around this issue, and that they can
not afford that. I was trying to be that voice of reason if that is
the road/excuse they are choosing to go.
There seem to be acceptable workarounds, solid proposed workarounds,
etc. I guess I am not getting it, JSON is just a string returned,
yes, it can represent type of data, but it is still just a
string. I
can not see it being that huge a performance hit to massage that
string a bit once you get ahold of it.
--
Scott * If you contact me off list replace talklists@ with scott@ *
On Sep 25, 2009, at 2:02 PM, jmathai wrote:
It's ridiculous to suggest a change in hardware (64 bit) or
software
(switch from PHP) to use Twitter's API. It's not like either of
these
are archaic. It sucks, sure, but it's silly to suggest such a
"solution".
BTW, I don't have this problem. I'm just trying to be the voice of
reason.
