+1. For this and other reasons the API should be versioned. Jim Renkel
-----Original Message----- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Scott Haneda Sent: Friday, September 25, 2009 21:28 To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: SERIOUS Problem With Cursors In JSON Followers/Friends Ids 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. >
