+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
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.

Reply via email to