clearly realized that the switch-over might be a little bumpy, and that’s why they started alerting third-party developers about it months ago. But it turns out it’s even more bumpy than they realized. And that’s why the transition hasn’t happened yet. And won’t for a while.

A post today by developer advocate Matt Harris in the Twitter Development Talk Google Group outlines what is going on. It’s a bit technical, and if you’re a developer, you should obviously read the whole thing. It boils down to this: some programming languages, notably JavaScript, cannot support numbers with more than 53 bits. That’s a problem since Snowflake is going to create tweet IDs that are 64 bit unsigned integers.

Writes Harris:

To allow javascript and JSON parsers to read the IDs we need to include a string version of any ID when responding in the JSON format. What this means is Status, User, Direct Message and Saved Search IDs in the Twitter API will now be returned as an integer and a string in JSON responses. This will apply to the main Twitter API, the Streaming API and the Search API.

So, if you have developed your Twitter app using JavaScript, you need to update your code to read this string version of the tweet ID instead of the integer version. In other words, a lot of developers are likely going to have to alter their code to keep things kosher.

Luckily, you have some more time. Harris notes that this coming Friday (October 22), they will start placing string versions of tweet IDs in the API. On November 4, the plan is then to activate Snowflake, but limit tweet IDs to 41 bits. But on November 26, these IDs will go longer than 53 bits, so you’ll need to have your updated code in place by then.

It’s sort of like a mini Twitpocalypse of sorts. Or maybe a Twlizzard? Third-party Twitter developers: be sure to check your code.

[photo: flickr/sarah ackerman] [thanks Alex]

0 0

7 7

Authors: MG Siegler

to know more click here