oups.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 v
; [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
>&
e-
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
@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
I actually like the idea of versioning the API. Having an API version
that returns all values as strings can be as simple on the Twitter
side as an IF statement in the final stages of constructing the JSON
output that just converts all numerical values to strings before the
JSON encode.
Dewald
O
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 P
Dewald sums it up great. I'm not affected by this issue but keeping
the barrier of entry low is of high value. It sucks that some PHP
installations have this issue, but if there's a good way to accomodate
such a popular language then what's the harm?
This brings up an issue though. I'm not in
I think the point that some folks are trying to make is that forcing
consumers of the API to use 64-bit machines is stifling innovation.
Many Twitter apps start as pet projects hosted on a shared HostGator
or other provider's server for nine bucks a month. That's how mine
started way back. You do
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 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
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 wrote:
> I would not change either. But there are those here that are stating
> they need
On Fri, Sep 25, 2009 at 5:16 PM, Scott Haneda wrote:
>
> I can not see it
> being that huge a performance hit to massage that string a bit once you get
> ahold of it.
Precisely. If you really want to turn the numbers into strings in PHP,
here are 2 workaround examples. Please note, I use PHP per
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,
> You either need to run on a newer system or use a language that can
> properly handle 64-bit numbers. C, Python, Ruby, Scala, Erlang, C#,
> etc none of them have problems with 64-bit ints.
Heck, Perl does it fine. I run TTYtter on a 32-bit system that runs a Perl
that's over 10 years old, a
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.
On Sep
I tend to agree, a MacMini, around 600.00, would build php out as 64
bit no issue. If you are a baby startup, that should really cover you
and be able to handle a lot more load than you would think. You may
have to pop your database on something more robust, but it works quite
well as a
I don't think anyone's saying it's Twitter's problem (at least I hope
not). It's the same issue as supporting Internet Explorer. You can
bitch and complain all you want about IE not supporting standards but
if it's the most popular (or one of the most popular) browsers that
are in use --- then p
I'm sorry, but the problem isn't Twitter- its your language and JSON
parser. Outputting everything as a string, when it clearly should be a
number, is inefficient and crazy.
Saying that startups can't afford 64 bit processors in systems is
crazy. Most startups I know are running on EC2 or have fa
If you are on 32 bit, what php.ini changes are you referring to that
would be beneficial?
--
Scott
Iphone says hello.
On Sep 25, 2009, at 10:35 AM, jmathai wrote:
I like Abraham's idea:
Twitter could add: "next_cursor_string":"1314614526448841129"
Or a general return_as_string paramet
I like Abraham's idea:
>>Twitter could add: "next_cursor_string":"1314614526448841129"
Or a general return_as_string parameter which would return all values
as strings. This would solve the problem for future values that might
exceed the max int. There are going to be a lot of devs using PHP
th
Can someone explain this issue to me in more detail?
How do I know my php can handle it? I'm running on an older PPC
machine, which is 64 bit, but I have no idea if I built it as 64, I
just supplied standard configure arguments.
If php sees a 64 bit integer come in as JSON what happens on
For reference, the PHP_INT_MAX on my 64-bit linux VM is:
9223372036854775807
and using json_decode on the next_cursor field of an ids list works just fine.
I'm using PHP 5.2.10-0.dotdeb.1 (though PHP 5.2.11-0.dotdeb.1 is available)
fwiw,
-Chad
On Thu, Sep 24, 2009 at 3:29 PM, Dewald Pretorius
That magical maximum number appears to be 1 (1.0E+12).
So, for tweet ids we still have a bit of breathing space.
Dewald
On Sep 24, 4:18 pm, Dewald Pretorius wrote:
> Clearly PHP_INT_MAX plays no role in json_decode.
>
> There must be some other mystical maximum number above which i
Clearly PHP_INT_MAX plays no role in json_decode.
There must be some other mystical maximum number above which it
represents the number as float in the decoded data.
Dewald
On Sep 24, 4:05 pm, Dewald Pretorius wrote:
> Chad,
>
> PHP_INT_MAX is 2147483647.
>
> And yet, json_decode is still corr
um...
"As mentioned previously, the Twitter operations team will artificially
increase the maximum status ID to 4294967296 this coming Friday,
September 11th. This action is part of routine database upgrades and
maintenance. "
http://groups.google.com/group/twitter-development-talk/browse_thread
Chad,
PHP_INT_MAX is 2147483647.
And yet, json_decode is still correctly decoding "id":4348298957.
O-o
Dewald
On Sep 24, 3:58 pm, Chad Etzel wrote:
> Dewald,
>
> What do you get on your server if you do:
>
> echo PHP_INT_MAX;
>
> also, what version of PHP are you using?
>
> -Chad
Dewald,
What do you get on your server if you do:
echo PHP_INT_MAX;
also, what version of PHP are you using?
-Chad
On Thu, Sep 24, 2009 at 2:48 PM, Dewald Pretorius wrote:
>
> Although, looking at a few tweets in the public timeline, I'm seeing
> tweet ids of 4348298962, 4348298957, etc.
>
>
On Thu, Sep 24, 2009 at 2:29 PM, Joseph Cheek wrote:
>
> already past 32-bit signed but not 32-bit unsigned, right?
> twitpocalypse moves the max to 2^32-1, right? or did i misread it?
They have passed 32-bit *un*signed. My latest tweet id is 4345383616
(which is > 2^32 - 1)
Twitpocalypse 2 w
Although, looking at a few tweets in the public timeline, I'm seeing
tweet ids of 4348298962, 4348298957, etc.
At least on my server, json_decode is still correctly decoding those
numbers.
So, it's probably safe to say that Twitpocalypse 2 has not arrived yet
for many PHP apps in terms of JSON d
already past 32-bit signed but not 32-bit unsigned, right?
twitpocalypse moves the max to 2^32-1, right? or did i misread it?
Chad Etzel wrote:
> This has already happened. Tweet ids are now bigger than a 32 bit int
> can store. That's what Twitpocalypse 2 was all about.
>
> -Chad
>
--
Jo
until 65+ bit computing becomes standard, a lot of things will break
(twitter included) when id's go past 64 bits. i hate to be a naysayer
though, but the difference between 2^32 and 2^64 is, well, huge. i
don't expect twitter id's to break 64 bits anytime soon, until at least
far past twitter's
Chad,
Thanks for setting me straight on that one.
My app is not reliant on Twitter tweet ids except for one specific
informational use. Hence, I have not been paying much attention to the
Twitpocalypse 2.
Dewald
On Sep 24, 3:14 pm, Chad Etzel wrote:
> On Thu, Sep 24, 2009 at 1:50 PM, Dewald P
On Thu, Sep 24, 2009 at 1:50 PM, Dewald Pretorius wrote:
>
> Abraham,
>
> That is true, but we are going to run into exactly the same problem
> with 64-bit status ids.
This has already happened. Tweet ids are now bigger than a 32 bit int
can store. That's what Twitpocalypse 2 was all about.
-Ch
Abraham,
That is true, but we are going to run into exactly the same problem
with 64-bit status ids.
And that is going to break a LOT of PHP applications in one fell
swoop.
Dewald
On Sep 24, 2:27 pm, Abraham Williams <4bra...@gmail.com> wrote:
> Twitter could add:
> "next_cursor_string":"13146
lto:twitter-development-t...@googlegroups.com] On Behalf Of Dewald
Pretorius
Sent: Thursday, September 24, 2009 10:26
To: Twitter Development Talk
Subject: [twitter-dev] Re: SERIOUS Problem With Cursors In JSON
Followers/Friends Ids
Provided that it will not break the JSON for other language apps,
Twitter could add:
"next_cursor_string":"1314614526448841129"
Minimal cost and it would be backwards compatible.
Abraham
On Thu, Sep 24, 2009 at 12:06, Dewald Pretorius wrote:
>
> Jesse,
>
> It will add exactly two quote characters (") per numeric field in the
> JSON payload.
>
> In any event,
Jesse,
It will add exactly two quote characters (") per numeric field in the
JSON payload.
In any event, I am now hacking the raw JSON output to convert the ids
and cursors to string. It's not an ideal solution but it works.
Dewald
On Sep 24, 12:34 pm, Jesse Stay wrote:
> On Thu, Sep 24, 2009
My 2 cents are:1. we're using the xml form of the api on 32bit development
machines and it works fine.
2. not supporting 32bit machines seems like a bad idea for twitter and
developers, no matter who(twitter or php) you want to blame as the problem;
a) PHP is perhaps the most popular web developm
On Thu, Sep 24, 2009 at 9:26 AM, Dewald Pretorius wrote:
> This goes for any large numbers, including tweet ids. As far as I am
> concerned they can output everything in JSON as strings.
>
>
That would create quite a memory footprint! I prefer to use ints where
possible and strings only where nec
Provided that it will not break the JSON for other language apps, the
solution is extremely simple for Twitter to implement, and it will
save a lot of us a lot of work and expense.
Just create any large numeric values in the JSON output as strings,
instead of numbers.
This goes for any large num
Agreed that the problem isn't Twitter's fault. But a basic feature
like cursor should work in a language as popular as PHP. Not so much
in principle but in practice.
Has anyone tried PEAR's Services_JSON? I haven't tried nor looked at
the source. It's also slower than the native json_* functio
To be fair to Twitter, the problem lies in PHP's json_decode() function,
not the twitter API.
Joseph Cheek
jos...@cheek.com, www.cheek.com
twitter: http://twitter.com/cheekdotcom
Dewald Pretorius wrote:
> Chad,
>
> Shouldn't Twitter be providing an API that works for everyone?
>
> From what yo
Chad,
Shouldn't Twitter be providing an API that works for everyone?
>From what you said it sounds as if you're saying, "Tough. If you want
to consume the API with PHP, either run your stuff on a 64-bit
machine, or scrape the raw JSON output and make it so that it works
for you."
That doesn't s
Hello,
As Joseph points out, PHP on a 64-bit system can handle these numbers.
If you really want this data as a string, you could write a regex in
PHP to alter the json string to wrap the digits in quotes before
sending it through json_decode(), but that would be a pretty gnarly
kludge.
-Chad
All that Twitter needs to do to solve this problem is to build the
JSON out with next_cursor and previous_cursor as string values.
I.e., the JSON data should contain:
"next_cursor":"12398712981212987","previous_cursor":"-12398712981212987"
I don't know what it will do to Java apps, but for PHP
from http://us2.php.net/json_decode:
|In PHP <= 5.1.6 trying to decode an integer value that's > PHP_INT_MAX
will result in an intger of PHP_INT_MAX.
In PHP 5.2+ decoding an integer > PHP_INT_MAX will cause a conversion to
a float.
Neither behaviour is perfect, capping at PHP_INT_MAX is margina
45 matches
Mail list logo
