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
that
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 jmat...@gmail.com wrote:
I like Abraham's idea:
Twitter could add: next_cursor_string:1314614526448841129
Or a general
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
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
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
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
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, and
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,
On Fri, Sep 25, 2009 at 5:16 PM, Scott Haneda talkli...@newgeo.com 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
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
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
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
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
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
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
@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
: 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
: 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
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
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_*
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
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 dpr...@gmail.com wrote:
Jesse,
It will add exactly two quote characters () per numeric field in the
JSON payload.
In any
...@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, the
solution is extremely simple
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:
On Thu, Sep 24, 2009 at 1:50 PM, Dewald Pretorius dpr...@gmail.com 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
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 c...@twitter.com wrote:
On Thu, Sep 24, 2009 at
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
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
--
Joseph
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
On Thu, Sep 24, 2009 at 2:29 PM, Joseph Cheek jos...@cheek.com 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)
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 dpr...@gmail.com wrote:
Although, looking at a few tweets in the public timeline, I'm seeing
tweet ids of 4348298962,
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 c...@twitter.com 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
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.
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 dpr...@gmail.com wrote:
Chad,
PHP_INT_MAX is 2147483647.
And yet, json_decode
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 dpr...@gmail.com wrote:
Clearly PHP_INT_MAX plays no role in json_decode.
There must be some other mystical maximum number
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
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
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
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 apps it
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
40 matches
Mail list logo
