Re: [twitter-dev] Error 500 messages
Yes! And its happening for the last 2-3 days. May be something is wrong on Twitter's part. On Fri, Mar 26, 2010 at 9:12 AM, Cory cory.imdi...@gmail.com wrote: I'm getting a bunch of Error 500 messages from different API calls today - is anyone else experiencing this? It isn't every call, but it's a good 1/3 of them. Sometimes a call will succeed, sometimes it will fail. The method being called doesn't seem to make a difference. I'm using oAuth, not sure if that matters. To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Thanks Regards Rajiv Verma Bangalore E-Mail: rajiv@gmail.com Ph: +91-92430-12766 Go Green, Use minimum natural resources! To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Just stated working
Hi , ive just started working on twitter application on c# and using Yedda twitter class , can somebody give me a basic simple application or somebody tell me what is To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Just stated working
I am using the Twitterizer Framework. On Fri, Mar 26, 2010 at 10:55 AM, sardar ahmed sardarahm...@gmail.comwrote: Hi , ive just started working on twitter application on c# and using Yedda twitter class , can somebody give me a basic simple application or somebody tell me what is OutputFormatType.For example in parameters of some method what would be OutputFormatType. To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Thanks Regards Rajiv Verma Bangalore E-Mail: rajiv@gmail.com Ph: +91-92430-12766 Go Green, Use minimum natural resources! To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Error 500 messages
Do these errors coincide with this incident? http://status.twitter.com/post/473971477/high-error-rate-and-page-loading-issues We threw a lot of 500s during this hour, and the 500s been slightly elevated from baseline since that issue was largely resolved. Ops is grinding down that error rate as I type. -John Kalucki http://twitter.com/jkalucki Infrastructure, Twitter Inc. On Thu, Mar 25, 2010 at 8:42 PM, Cory cory.imdi...@gmail.com wrote: I'm getting a bunch of Error 500 messages from different API calls today - is anyone else experiencing this? It isn't every call, but it's a good 1/3 of them. Sometimes a call will succeed, sometimes it will fail. The method being called doesn't seem to make a difference. I'm using oAuth, not sure if that matters. To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Error 500 messages
Well!! Not exactly!! what I was getting is Authentication Failed and Server Timeout On Fri, Mar 26, 2010 at 12:11 PM, John Kalucki j...@twitter.com wrote: Do these errors coincide with this incident? http://status.twitter.com/post/473971477/high-error-rate-and-page-loading-issues We threw a lot of 500s during this hour, and the 500s been slightly elevated from baseline since that issue was largely resolved. Ops is grinding down that error rate as I type. -John Kalucki http://twitter.com/jkalucki Infrastructure, Twitter Inc. On Thu, Mar 25, 2010 at 8:42 PM, Cory cory.imdi...@gmail.com wrote: I'm getting a bunch of Error 500 messages from different API calls today - is anyone else experiencing this? It isn't every call, but it's a good 1/3 of them. Sometimes a call will succeed, sometimes it will fail. The method being called doesn't seem to make a difference. I'm using oAuth, not sure if that matters. To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Thanks Regards Rajiv Verma Bangalore E-Mail: rajiv@gmail.com Ph: +91-92430-12766 Go Green, Use minimum natural resources! To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] share user account activity data?
I'd love a list of id's for active accounts and another list of id's for inactive ones, by some sensible criteria of activity. Publishing this is in twitter.com's interest, admittedly for that large first and second crawl. I'm calling this for everyone: http://twitter.com/friends/ids.xml/?user_id=12345 And I need to call it again after some time passes to determine activity. Maybe there's a good alternative? I'm not belly-aching about the two complete canvases, but I think i calculated that it takes my whitelisted application 145 days to complete from now, consuming its full allotment of 20k every hour of every day. Is that right? well it's close. I'm very new to the scene so please tip me off if there's a shortcut datasource that reports inactive accounts, so i can dial api traffic about inactives way back. i'd love a bulk appraisal of account activity/inactivity as a binary condition or in any other flavor (status update is another sensible source as an activity inference). all clues appreciated. thanks cats! john To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] What's the IP range of api.twitter.com?
The addresses vary dynamically and the range is subject to change without notice at any time. You can observe typical values with ping or dig and enter these into your firewall. I'd suggest at least a /24 netmask, as you may not observe all the possible values within a given period. I'd also then expect periods of downtime with this security policy. -John Kalucki http://twitter.com/jkalucki Infrastructure, Twitter Inc. On Fri, Mar 26, 2010 at 2:51 AM, planck pla...@gmail.com wrote: Why hello there, I have an application running behind a very restrictive firewall and need to allow connections specifically to the Twitter API. Any ideas on what the IP range of the API is? Thanks, Christian To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Twitter provider url support for openid login
Hi, I was actually started integrating with login sso with openid. I thought of integrating for twitter also. Do we have twitter provider url support for openid login integration? Thanks Venkata To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] share user account activity data?
Stop doing this. You are stressing the system and producing questionable results. You run a very high risk of blacklisting. Also, there are many many existing studies that go over this same ground of active users and break the data down in painstaking detail. Instead, take the Spritzer sample feed on the Streaming API if you must collect this data. This feed will, over time, give you a very accurate picture of active accounts, which I think you mean tweeting accounts. Many users are active without tweeting, or without even ever logging in to Twitter. -John Kalucki http://twitter.com/jkalucki Infrastructure, Twitter Inc. On Fri, Mar 26, 2010 at 12:38 AM, mcfnord mcfn...@gmail.com wrote: I'd love a list of id's for active accounts and another list of id's for inactive ones, by some sensible criteria of activity. Publishing this is in twitter.com's interest, admittedly for that large first and second crawl. I'm calling this for everyone: http://twitter.com/friends/ids.xml/?user_id=12345 And I need to call it again after some time passes to determine activity. Maybe there's a good alternative? I'm not belly-aching about the two complete canvases, but I think i calculated that it takes my whitelisted application 145 days to complete from now, consuming its full allotment of 20k every hour of every day. Is that right? well it's close. I'm very new to the scene so please tip me off if there's a shortcut datasource that reports inactive accounts, so i can dial api traffic about inactives way back. i'd love a bulk appraisal of account activity/inactivity as a binary condition or in any other flavor (status update is another sensible source as an activity inference). all clues appreciated. thanks cats! john To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Twitter provider url support for openid login
Hi Venkata, Twitter is not an OpenId provider. Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Fri, Mar 26, 2010 at 4:14 AM, pammi venkatareddy.pa...@gmail.com wrote: Hi, I was actually started integrating with login sso with openid. I thought of integrating for twitter also. Do we have twitter provider url support for openid login integration? Thanks Venkata To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Tweets number changed
Does anyone know why tweets are disappearing from twitter? To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Bulk User Lookups
I just want to say thank you for the new users/lookup API method, and for removing the secondary limits. It has improved the response times in relevant areas of my app by orders of magnitude. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Sample twitter application
I'm going to guess that you don't have shell access on that machine.
Make sure your web host can contact api.twitter.com. One way to do
that is with this command curl -v
http://api.twitter.com/1/statuses/public_timeline.rss
If there's an error or no output then your host has to figure out why
they can't connect to api.twitter.com from that machine.
On Mar 25, 11:54 pm, Dushyant dushyantaror...@gmail.com wrote:
I did what you said now I get the following output
Curl error: couldn't connect to host
Error: 0
On Mar 25, 7:39 pm, natefanaro natefan...@gmail.com wrote:
At first glance there are two things you want to change. The $url
should be changed tohttp://api.twitter.com/1/statuses/update.format
Not sure why you're trying to run that through a proxy on port 80 but
that should be why you're receiving the 404. Remove this line
curl_setopt($ch, CURLOPT_PROXY,localhost:80);
On Mar 25, 7:37 am, Dushyant dushyantaror...@gmail.com wrote:
I have installed WAMP and running PHP scripts on localhost. I have
enabled cURL. Here is my code.
?php
function updateTwitter($status)
{
// Twitter login information
$username = 'x';
$password = 'x';
// The url of the update function
$url = 'http://twitter.com/statuses/update.xml';
// Arguments we are posting to Twitter
$postargs = 'status='.urlencode($status);
// Will store the response we get from Twitter
$responseInfo=array();
// Initialize CURL
$ch = curl_init($url);
// Tell CURL we are doing a POST
curl_setopt($ch, CURLOPT_PROXY,localhost:80);
curl_setopt ($ch, CURLOPT_POST, true);
// Give CURL the arguments in the POST
curl_setopt ($ch, CURLOPT_POSTFIELDS, $postargs);
// Set the username and password in the CURL call
curl_setopt($ch, CURLOPT_USERPWD, $username.':'.$password);
// Set some cur flags (not too important)
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt($ch, CURLOPT_NOBODY, 0);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION,1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
// execute the CURL call
$response = curl_exec($ch);
if($response === false)
{
echo 'Curl error: ' . curl_error($ch);}
else
{
echo 'Operation completed without any errorsbr/';
}
// Get information about the response
$responseInfo=curl_getinfo($ch);
// Close the CURL connection curl_close($ch);
// Make sure we received a response from Twitter
if(intval($responseInfo['http_code'])==200){
// Display the response from Twitter
echo $response;
}else{
// Something went wrong
echo Error: . $responseInfo['http_code'];
}
curl_close($ch);
}
updateTwitter(Test tweet);
?
Here's my output
Operation completed without any errors
Error: 404
Please help.
To unsubscribe from this group, send email to
twitter-development-talk+unsubscribegooglegroups.com or reply to this email
with the words REMOVE ME as the subject.
[twitter-dev] Retweet via Shows Wrong App?
When posting a retweet to the API, twitter.com is displaying an incorrect via app name. Is this a known issue or am I doing something wrong? The via app name displayed is correct when posting new statuses and replies. I'm using the MGTwitterEngine and http://github.com/bengottlieb/Twitter-OAuth-iPhone in an iPad app. You can see 5 retweets on this page claiming to be retweeted via UberTwitter and twitterfeed, when they should say via Nightline Test instead... like the rest of the updates do: http://twitter.com/davidcanntest2 Thanks, David To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Streaming API -- filtering with punctuation
Hey guys, Is it at all possible, in some way or another to specify a filter with a period? I've been working on an image streaming service and up till now I have been just filtering on: twitpic,yfrog,pic However, we'd also like to stream in links from ow.ly, but I would have to filter on ow to make this happen, which would return a lot of unnecessary tweets which is a load on the streaming service and my daemon. Thanks! Peter To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Retweet via Shows Wrong App?
Via will show the app the original tweet was submitted with... On Mar 26, 2010, at 10:17 AM, David Cann davidjc...@gmail.com wrote: When posting a retweet to the API, twitter.com is displaying an incorrect via app name. Is this a known issue or am I doing something wrong? The via app name displayed is correct when posting new statuses and replies. I'm using the MGTwitterEngine and http://github.com/bengottlieb/Twitter-OAuth-iPhone in an iPad app. You can see 5 retweets on this page claiming to be retweeted via UberTwitter and twitterfeed, when they should say via Nightline Test instead... like the rest of the updates do: http://twitter.com/davidcanntest2 Thanks, David To unsubscribe from this group, send email to twitter-development- talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Streaming API -- filtering with punctuation
The combinatorics don't work out here until we offer boolean AND. Tokens are thrown against a HashMap to determine delivery. It's not really feasible to also throw arbitrary combinations of tokens against the HashMap. If we ever support AND, then you could search for ow AND ly. You'll have to over-request and filter on your end. -John Kalucki http://twitter.com/jkalucki Infrastructure, Twitter Inc. On Fri, Mar 26, 2010 at 8:34 AM, Peter Kieltyka peter.kielt...@nulayer.comwrote: Hey guys, Is it at all possible, in some way or another to specify a filter with a period? I've been working on an image streaming service and up till now I have been just filtering on: twitpic,yfrog,pic However, we'd also like to stream in links from ow.ly, but I would have to filter on ow to make this happen, which would return a lot of unnecessary tweets which is a load on the streaming service and my daemon. Thanks! Peter To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] JavaScript XAuth library ??????
Hi guys i can't wrap my head around OAuth/XAuth for browserless apps is there any JavaScript Library for easy working with XAuth To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Streaming API -- filtering with punctuation
On 03/26/2010 10:32 AM, John Kalucki wrote: The combinatorics don't work out here until we offer boolean AND. Tokens are thrown against a HashMap to determine delivery. It's not really feasible to also throw arbitrary combinations of tokens against the HashMap. If we ever support AND, then you could search for ow AND ly. You'll have to over-request and filter on your end. This may have to wait till Chirp, but as long as we're on the subject of filtering at the consumer end, how good is *Cassandra* at that sort of filtering, relative to all the other databases, NoSQL and traditional ACID-compliant RDBMS? And how good is Cassandra relative to Hadoop? I've been thinking PostgreSQL in my designs, mostly because it's the one I know best, it's solid as a rock and I have friends who will disown me if I use MySQL. ;-) But using the same DB as Twitter has an appeal to it just because you *do* use it. And, of course, because NoSQL databases are cool and geeky. ;-) To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Retweet via Shows Wrong App?
Ok, thanks. On Mar 26, 1:31 pm, Michael Steuer mste...@gmail.com wrote: Via will show the app the original tweet was submitted with... On Mar 26, 2010, at 10:17 AM, David Cann davidjc...@gmail.com wrote: When posting a retweet to the API, twitter.com is displaying an incorrect via app name. Is this a known issue or am I doing something wrong? The via app name displayed is correct when posting new statuses and replies. I'm using the MGTwitterEngine andhttp://github.com/bengottlieb/Twitter-OAuth-iPhone in an iPad app. You can see 5 retweets on this page claiming to be retweeted via UberTwitter and twitterfeed, when they should say via Nightline Test instead... like the rest of the updates do: http://twitter.com/davidcanntest2 Thanks, David To unsubscribe from this group, send email to twitter-development- talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Streaming API -- filtering with punctuation
You really shouldn't pick your systems based on what Twitter uses unless all else is the same. Our requirements are radically different from yours. I'd encourage you to use the same libraries though -- for example, if we're using Gson to parse JSON, you are unlikely to run into additional complications. On Fri, Mar 26, 2010 at 10:41 AM, M. Edward (Ed) Borasky zzn...@gmail.comwrote: On 03/26/2010 10:32 AM, John Kalucki wrote: The combinatorics don't work out here until we offer boolean AND. Tokens are thrown against a HashMap to determine delivery. It's not really feasible to also throw arbitrary combinations of tokens against the HashMap. If we ever support AND, then you could search for ow AND ly. You'll have to over-request and filter on your end. This may have to wait till Chirp, but as long as we're on the subject of filtering at the consumer end, how good is *Cassandra* at that sort of filtering, relative to all the other databases, NoSQL and traditional ACID-compliant RDBMS? And how good is Cassandra relative to Hadoop? I've been thinking PostgreSQL in my designs, mostly because it's the one I know best, it's solid as a rock and I have friends who will disown me if I use MySQL. ;-) But using the same DB as Twitter has an appeal to it just because you *do* use it. And, of course, because NoSQL databases are cool and geeky. ;-) To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Streaming API -- filtering with punctuation
Ed, For app side filtering, you may want to look at Sphinx Search: http://www.sphinxsearch.com/ On Mar 26, 2:41 pm, M. Edward (Ed) Borasky zzn...@gmail.com wrote: On 03/26/2010 10:32 AM, John Kalucki wrote: The combinatorics don't work out here until we offer boolean AND. Tokens are thrown against a HashMap to determine delivery. It's not really feasible to also throw arbitrary combinations of tokens against the HashMap. If we ever support AND, then you could search for ow AND ly. You'll have to over-request and filter on your end. This may have to wait till Chirp, but as long as we're on the subject of filtering at the consumer end, how good is *Cassandra* at that sort of filtering, relative to all the other databases, NoSQL and traditional ACID-compliant RDBMS? And how good is Cassandra relative to Hadoop? I've been thinking PostgreSQL in my designs, mostly because it's the one I know best, it's solid as a rock and I have friends who will disown me if I use MySQL. ;-) But using the same DB as Twitter has an appeal to it just because you *do* use it. And, of course, because NoSQL databases are cool and geeky. ;-) To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Search Weirdness?
I have a search request that doesnt seem to work properly. I noticed
when I was trying to refresh and no new posts were coming in, but it
appears to not be working even on first search
I have include the HTTP request and response, below, you can see that
no results are returned, however a max_id is returned indicating that
search believes it returned messages and hence any future refresh will
be missing anything that should have been delivered. Also, I know this
search should be returning results.
Request:
GET /search.json?q=Socialscope+OR+%2522social+scope%2522rpp=200 HTTP/
1.1
User-Agent: TestUserAgent
Response:
HTTP/1.1 200 OK
Date: Fri, 26 Mar 2010 19:05:30 GMT
Server: hi
Status: 200 OK
X-Served-From: b005
X-Runtime: 0.89185
Content-Type: application/json; charset=utf-8
X-Served-By: c005.twitter.com
X-Timeline-Cache-Hit: Miss
Cache-Control: max-age=15, must-revalidate, max-age=300
Expires: Fri, 26 Mar 2010 19:10:30 GMT
Content-Length: 230
Vary: Accept-Encoding
X-Varnish: 1840907505
Age: 0
Via: 1.1 varnish
X-Cache-Svr: c005.twitter.com
X-Cache: MISS
Connection: close
{results:[],max_id:11102103671,since_id:0,refresh_url:?
since_id=11102103671q=Socialscope+OR+%2522social+scope
%2522,results_per_page:100,page:1,completed_in:
0.879457,query:Socialscope+OR+%2522social+scope%2522}
To unsubscribe from this group, send email to
twitter-development-talk+unsubscribegooglegroups.com or reply to this email
with the words REMOVE ME as the subject.
[twitter-dev] Re: Sample twitter application
thanks a lot. The problem was with my host. They had blocked
fsockopen() function call.
On Mar 26, 8:14 pm, natefanaro natefan...@gmail.com wrote:
I'm going to guess that you don't have shell access on that machine.
Make sure your web host can contact api.twitter.com. One way to do
that is with this command curl
-vhttp://api.twitter.com/1/statuses/public_timeline.rss
If there's an error or no output then your host has to figure out why
they can't connect to api.twitter.com from that machine.
On Mar 25, 11:54 pm, Dushyant dushyantaror...@gmail.com wrote:
I did what you said now I get the following output
Curl error: couldn't connect to host
Error: 0
On Mar 25, 7:39 pm, natefanaro natefan...@gmail.com wrote:
At first glance there are two things you want to change. The $url
should be changed tohttp://api.twitter.com/1/statuses/update.format
Not sure why you're trying to run that through a proxy on port 80 but
that should be why you're receiving the 404. Remove this line
curl_setopt($ch, CURLOPT_PROXY,localhost:80);
On Mar 25, 7:37 am, Dushyant dushyantaror...@gmail.com wrote:
I have installed WAMP and running PHP scripts on localhost. I have
enabled cURL. Here is my code.
?php
function updateTwitter($status)
{
// Twitter login information
$username = 'x';
$password = 'x';
// The url of the update function
$url = 'http://twitter.com/statuses/update.xml';
// Arguments we are posting to Twitter
$postargs = 'status='.urlencode($status);
// Will store the response we get from Twitter
$responseInfo=array();
// Initialize CURL
$ch = curl_init($url);
// Tell CURL we are doing a POST
curl_setopt($ch, CURLOPT_PROXY,localhost:80);
curl_setopt ($ch, CURLOPT_POST, true);
// Give CURL the arguments in the POST
curl_setopt ($ch, CURLOPT_POSTFIELDS, $postargs);
// Set the username and password in the CURL call
curl_setopt($ch, CURLOPT_USERPWD, $username.':'.$password);
// Set some cur flags (not too important)
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt($ch, CURLOPT_NOBODY, 0);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION,1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
// execute the CURL call
$response = curl_exec($ch);
if($response === false)
{
echo 'Curl error: ' . curl_error($ch);}
else
{
echo 'Operation completed without any errorsbr/';
}
// Get information about the response
$responseInfo=curl_getinfo($ch);
// Close the CURL connection curl_close($ch);
// Make sure we received a response from Twitter
if(intval($responseInfo['http_code'])==200){
// Display the response from Twitter
echo $response;
}else{
// Something went wrong
echo Error: . $responseInfo['http_code'];
}
curl_close($ch);
}
updateTwitter(Test tweet);
?
Here's my output
Operation completed without any errors
Error: 404
Please help.
To unsubscribe from this group, send email to
twitter-development-talk+unsubscribegooglegroups.com or reply to this email
with the words REMOVE ME as the subject.
Re: [twitter-dev] Re: Streaming API -- filtering with punctuation
On 03/26/2010 11:54 AM, Dewald Pretorius wrote: Ed, For app side filtering, you may want to look at Sphinx Search: http://www.sphinxsearch.com/ Yeah, I've seen Sphinx and all the Lucene clones and Namazu and half a dozen others. My natural inclination has been toward PostgreSQL's built-in text search, but I haven't seen a large community built up around that like I have with the others. In the end, I'll most likely end up with my own custom Perl / PostgreSQL code, because most open-source licenses are too restrictive, I don't know Python or Java well, and Ruby is too slow. PostgreSQL uses a BSD license, which is a good thing. ;-) To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: JavaScript XAuth library ??????
from the OAuth.net page: http://oauth.net/code/ Scroll down and look for Javascript section. It links to this site: http://oauth.googlecode.com/svn/code/javascript/ I don't think this library sends the appropriate OAuth headers in the HTTP request. Or at least that isn't how I got it working. Instead, it sends all the appropriate stuff as HTTP request variables (either GET or POST, I cannot remember). It does perform the SHA1 stuff and makes the oauth_nonce and oauth_timestamp values for you. On Mar 26, 2:09 pm, mostafa farghaly keepon...@gmail.com wrote: Hi guys i can't wrap my head around OAuth/XAuth for browserless apps is there any JavaScript Library for easy working with XAuth To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Search by Client
On 03/21/2010 04:36 AM, Harshad RJ wrote: To test how this works I built a streaming parser for the Spritzer feed, and it occurred to me that I could make this data available to everyone. So, here it is: http://tdash.org/stats/clients I dunno if the OP just wanted an approx count of the client's tweets or the actual list of tweets. Personally, I would like to have both. It will be great if Twitter can allow search for source:myclient without requiring a keyword to be specified. I posted some of the results from this to my blog. A few people have questioned the high position of UberTwitter, which is Blackberry-only. As has been noted on this list, when a person uses the built-in retweet, the *original* posting client is the one that shows up, not the one the retweeter used. Could that account for the high ranking of UberTwitter? -- M. Edward (Ed) Borasky borasky-research.net/m-edward-ed-borasky A mathematician is a device for turning coffee into theorems. ~ Paul Erdős To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Upcoming changes to the way status IDs are sequenced
Hi Developers, It's no secret that Twitter is growing exponentially. The tweets keep coming with ever increasing velocity, thanks in large part to your great applications. Twitter has adapted to the increasing number of tweets in ways that have affected you in the past: We moved from 32 bit unsigned integers to 64-bit unsigned integers for status IDs some time ago. You all weathered that storm with ease. The tweetapoclypse was averted, and the tweets kept flowing. Now we're reaching the scalability limit of our current tweet ID generation scheme. Unlike the previous tweet ID migrations, the solution to the current issue is significantly different. However, in most cases the new approach we will take will not result in any noticeable differences to you the developer or your users. We are planning to replace our current sequential tweet ID generation routine with a simple, more scalable solution. IDs will still be 64-bit unsigned integers. However, this new solution is no longer guaranteed to generate sequential IDs. Instead IDs will be derived based on time: the most significant bits being sourced from a timestamp and the least significant bits will be effectively random. Please don't depend on the exact format of the ID. As our infrastructure needs evolve, we might need to tweak the generation algorithm again. If you've been trying to divine meaning from status IDs aside from their role as a primary key, you won't be able to anymore. Likewise for usage of IDs in mathematical operations -- for instance, subtracting two status IDs to determine the number of tweets in between will no longer be possible. For the majority of applications we think this scheme switch will be a non-event. Before implementing these changes, we'd like to know if your applications currently depend on the sequential nature of IDs. Do you depend on the density of the tweet sequence being constant? Are you trying to analyze the IDs as anything other than opaque, ordered identifiers? Aside for guaranteed sequential tweet ID ordering, what APIs can we provide you to accomplish your goals? Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
RE: [twitter-dev] Upcoming changes to the way status IDs are sequenced
Any app that pages through timelines uses since_id or max_id depends responses being ordered by tweet ID. What will be the replacement for since_id and max_id? Taylor Singletary wrote: We are planning to replace our current sequential tweet ID generation routine with a simple, more scalable solution. IDs will still be 64-bit unsigned integers. However, this new solution is no longer guaranteed to generate sequential IDs. Instead IDs will be derived based on time: the most significant bits being sourced from a timestamp and the least significant bits will be effectively random. For the majority of applications we think this scheme switch will be a non-event. Before implementing these changes, we'd like to know if your applications currently depend on the sequential nature of IDs. Do you depend on the density of the tweet sequence being constant? Are you trying to analyze the IDs as anything other than opaque, ordered identifiers? Aside for guaranteed sequential tweet ID ordering, what APIs can we provide you to accomplish your goals? To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Upcoming changes to the way status IDs are sequenced
For the majority of applications we think this scheme switch will be a non-event. Before implementing these changes, we'd like to know if your applications currently depend on the sequential nature of IDs. Do you depend on the density of the tweet sequence being constant? Are you trying to analyze the IDs as anything other than opaque, ordered identifiers? Aside for guaranteed sequential tweet ID ordering, what APIs can we provide you to accomplish your goals? I don't use the IDs as anything other than identifiers, and I can certainly sort an unordered stream, but I really do need since_id to work the same way it does now. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- LET'S GO FORWARD ... INTO THE PAST! To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Error 500 messages
I think that was it, it's been much better now. I was worried because I'm in the middle of development and I thought I broke something! On Mar 25, 11:41 pm, John Kalucki j...@twitter.com wrote: Do these errors coincide with this incident?http://status.twitter.com/post/473971477/high-error-rate-and-page-loa... We threw a lot of 500s during this hour, and the 500s been slightly elevated from baseline since that issue was largely resolved. Ops is grinding down that error rate as I type. -John Kaluckihttp://twitter.com/jkalucki Infrastructure, Twitter Inc. On Thu, Mar 25, 2010 at 8:42 PM, Cory cory.imdi...@gmail.com wrote: I'm getting a bunch of Error 500 messages from different API calls today - is anyone else experiencing this? It isn't every call, but it's a good 1/3 of them. Sometimes a call will succeed, sometimes it will fail. The method being called doesn't seem to make a difference. I'm using oAuth, not sure if that matters. To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Upcoming changes to the way status IDs are sequenced
Yup, I am using since_id as well in my application to perform various sequential tasks. Hopefully new id generation scheme will have this parameter support using some alternatives at least. Alam Sher On Sat, Mar 27, 2010 at 1:48 AM, Brian Smith br...@briansmith.org wrote: Any app that pages through timelines uses since_id or max_id depends responses being ordered by tweet ID. What will be the replacement for since_id and max_id? Taylor Singletary wrote: We are planning to replace our current sequential tweet ID generation routine with a simple, more scalable solution. IDs will still be 64-bit unsigned integers. However, this new solution is no longer guaranteed to generate sequential IDs. Instead IDs will be derived based on time: the most significant bits being sourced from a timestamp and the least significant bits will be effectively random. For the majority of applications we think this scheme switch will be a non-event. Before implementing these changes, we'd like to know if your applications currently depend on the sequential nature of IDs. Do you depend on the density of the tweet sequence being constant? Are you trying to analyze the IDs as anything other than opaque, ordered identifiers? Aside for guaranteed sequential tweet ID ordering, what APIs can we provide you to accomplish your goals? To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- ___ Alam Sher Khan +92 331 505 5549 To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] statuses/friends Not Found Error
I'm trying to run a query to grab the friends of the currently logged in user, and no matter what I do I get a Not Found error. Here is the request I'm making: http://api.twitter.com/statuses/friends.xml?id=coryimdiekeoauth_consumer_key=oauth_nonce=oauth_signature_method=HMAC-SHA1oauth_timestamp= 1269635891oauth_token=oauth_version=1.0oauth_signature= Response: ?xml version=1.0 encoding=UTF-8? hash errorNot found/error request/statuses/friends.xml? id=coryimdiekeamp;oauth_consumer_key=amp;oauth_nonce=amp;oauth_signature_method=HMAC- SHA1amp;oauth_timestamp=1269635891amp;oauth_token=amp;oauth_version=1.0amp;oauth_signature=/ request /hash I get the same response for that method regardless of how I try to call it. XML format, JSON format, with or without an id, user_id, with the id in the methodname instead of a parameter, etc. Same thing every time. My other calls all work fine. I can get statuses, check rate limit, verify_credentials, etc no problem. I've been fighting with this all night and I'm running out of ideas! Anyone have any thoughts? To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
I second this request, as a mobile developer since_id is essential for caching old tweets and only retreiving new tweets. since_id is invaluable. You say in most cases the new approach we will take will not result in any noticeable differences does that mean you will still handle a since_id being passed and if not how will we now use the API? On Mar 26, 8:48 pm, Brian Smith br...@briansmith.org wrote: Any app that pages through timelines uses since_id or max_id depends responses being ordered by tweet ID. What will be the replacement for since_id and max_id? Taylor Singletary wrote: We are planning to replace our current sequential tweet ID generation routine with a simple, more scalable solution. IDs will still be 64-bit unsigned integers. However, this new solution is no longer guaranteed to generate sequential IDs. Instead IDs will be derived based on time: the most significant bits being sourced from a timestamp and the least significant bits will be effectively random. For the majority of applications we think this scheme switch will be a non-event. Before implementing these changes, we'd like to know if your applications currently depend on the sequential nature of IDs. Do you depend on the density of the tweet sequence being constant? Are you trying to analyze the IDs as anything other than opaque, ordered identifiers? Aside for guaranteed sequential tweet ID ordering, what APIs can we provide you to accomplish your goals? To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
+1 on the need to maintain support for since_id in the Search API On Mar 27, 7:41 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, It's no secret that Twitter is growing exponentially. The tweets keep coming with ever increasing velocity, thanks in large part to your great applications. Twitter has adapted to the increasing number of tweets in ways that have affected you in the past: We moved from 32 bit unsigned integers to 64-bit unsigned integers for status IDs some time ago. You all weathered that storm with ease. The tweetapoclypse was averted, and the tweets kept flowing. Now we're reaching the scalability limit of our current tweet ID generation scheme. Unlike the previous tweet ID migrations, the solution to the current issue is significantly different. However, in most cases the new approach we will take will not result in any noticeable differences to you the developer or your users. We are planning to replace our current sequential tweet ID generation routine with a simple, more scalable solution. IDs will still be 64-bit unsigned integers. However, this new solution is no longer guaranteed to generate sequential IDs. Instead IDs will be derived based on time: the most significant bits being sourced from a timestamp and the least significant bits will be effectively random. Please don't depend on the exact format of the ID. As our infrastructure needs evolve, we might need to tweak the generation algorithm again. If you've been trying to divine meaning from status IDs aside from their role as a primary key, you won't be able to anymore. Likewise for usage of IDs in mathematical operations -- for instance, subtracting two status IDs to determine the number of tweets in between will no longer be possible. For the majority of applications we think this scheme switch will be a non-event. Before implementing these changes, we'd like to know if your applications currently depend on the sequential nature of IDs. Do you depend on the density of the tweet sequence being constant? Are you trying to analyze the IDs as anything other than opaque, ordered identifiers? Aside for guaranteed sequential tweet ID ordering, what APIs can we provide you to accomplish your goals? Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
We do not require that ids be sequential, but if the ids are not monotonically increasing it cause some issue with how we manage since_ids.. i.e. if a message posted by userA, 1 ns after userB, we would assume userB has a higher id than userA. While it may seem like nitpicking, wouldn't there a change userB message wont get delivered if its id is lower than userAs message and I happen to query the API just before userB but right after userA posted? --Naveen On Mar 26, 4:41 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, It's no secret that Twitter is growing exponentially. The tweets keep coming with ever increasing velocity, thanks in large part to your great applications. Twitter has adapted to the increasing number of tweets in ways that have affected you in the past: We moved from 32 bit unsigned integers to 64-bit unsigned integers for status IDs some time ago. You all weathered that storm with ease. The tweetapoclypse was averted, and the tweets kept flowing. Now we're reaching the scalability limit of our current tweet ID generation scheme. Unlike the previous tweet ID migrations, the solution to the current issue is significantly different. However, in most cases the new approach we will take will not result in any noticeable differences to you the developer or your users. We are planning to replace our current sequential tweet ID generation routine with a simple, more scalable solution. IDs will still be 64-bit unsigned integers. However, this new solution is no longer guaranteed to generate sequential IDs. Instead IDs will be derived based on time: the most significant bits being sourced from a timestamp and the least significant bits will be effectively random. Please don't depend on the exact format of the ID. As our infrastructure needs evolve, we might need to tweak the generation algorithm again. If you've been trying to divine meaning from status IDs aside from their role as a primary key, you won't be able to anymore. Likewise for usage of IDs in mathematical operations -- for instance, subtracting two status IDs to determine the number of tweets in between will no longer be possible. For the majority of applications we think this scheme switch will be a non-event. Before implementing these changes, we'd like to know if your applications currently depend on the sequential nature of IDs. Do you depend on the density of the tweet sequence being constant? Are you trying to analyze the IDs as anything other than opaque, ordered identifiers? Aside for guaranteed sequential tweet ID ordering, what APIs can we provide you to accomplish your goals? Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] GUIDs?
Why don't you just use GUIDs as your id and then just add a timedate attribute stamp and call it a day. That would give you a unique id and also give your tweets an order. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
Hi Taylor! Please comment on how this change will affect this bug: http://code.google.com/p/twitter-api/issues/detail?id=1529 Hopefully, the timestamp portion of the ID will allow since_id to work correctly when load increases. -ch On Mar 26, 1:41 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, It's no secret that Twitter is growing exponentially. The tweets keep coming with ever increasing velocity, thanks in large part to your great applications. Twitter has adapted to the increasing number of tweets in ways that have affected you in the past: We moved from 32 bit unsigned integers to 64-bit unsigned integers for status IDs some time ago. You all weathered that storm with ease. The tweetapoclypse was averted, and the tweets kept flowing. Now we're reaching the scalability limit of our current tweet ID generation scheme. Unlike the previous tweet ID migrations, the solution to the current issue is significantly different. However, in most cases the new approach we will take will not result in any noticeable differences to you the developer or your users. We are planning to replace our current sequential tweet ID generation routine with a simple, more scalable solution. IDs will still be 64-bit unsigned integers. However, this new solution is no longer guaranteed to generate sequential IDs. Instead IDs will be derived based on time: the most significant bits being sourced from a timestamp and the least significant bits will be effectively random. Please don't depend on the exact format of the ID. As our infrastructure needs evolve, we might need to tweak the generation algorithm again. If you've been trying to divine meaning from status IDs aside from their role as a primary key, you won't be able to anymore. Likewise for usage of IDs in mathematical operations -- for instance, subtracting two status IDs to determine the number of tweets in between will no longer be possible. For the majority of applications we think this scheme switch will be a non-event. Before implementing these changes, we'd like to know if your applications currently depend on the sequential nature of IDs. Do you depend on the density of the tweet sequence being constant? Are you trying to analyze the IDs as anything other than opaque, ordered identifiers? Aside for guaranteed sequential tweet ID ordering, what APIs can we provide you to accomplish your goals? Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Upcoming changes to the way status IDs are sequenced
How will this change affect the since Status_id type calls? I am working on a system that will depend on being able to download mentions once and only once, and was planning on using this function to ensure I got only what I wanted. Cheers, Nigel. On 26 March 2010 20:41, Taylor Singletary taylorsinglet...@twitter.comwrote: Hi Developers, It's no secret that Twitter is growing exponentially. The tweets keep coming with ever increasing velocity, thanks in large part to your great applications. Twitter has adapted to the increasing number of tweets in ways that have affected you in the past: We moved from 32 bit unsigned integers to 64-bit unsigned integers for status IDs some time ago. You all weathered that storm with ease. The tweetapoclypse was averted, and the tweets kept flowing. Now we're reaching the scalability limit of our current tweet ID generation scheme. Unlike the previous tweet ID migrations, the solution to the current issue is significantly different. However, in most cases the new approach we will take will not result in any noticeable differences to you the developer or your users. We are planning to replace our current sequential tweet ID generation routine with a simple, more scalable solution. IDs will still be 64-bit unsigned integers. However, this new solution is no longer guaranteed to generate sequential IDs. Instead IDs will be derived based on time: the most significant bits being sourced from a timestamp and the least significant bits will be effectively random. Please don't depend on the exact format of the ID. As our infrastructure needs evolve, we might need to tweak the generation algorithm again. If you've been trying to divine meaning from status IDs aside from their role as a primary key, you won't be able to anymore. Likewise for usage of IDs in mathematical operations -- for instance, subtracting two status IDs to determine the number of tweets in between will no longer be possible. For the majority of applications we think this scheme switch will be a non-event. Before implementing these changes, we'd like to know if your applications currently depend on the sequential nature of IDs. Do you depend on the density of the tweet sequence being constant? Are you trying to analyze the IDs as anything other than opaque, ordered identifiers? Aside for guaranteed sequential tweet ID ordering, what APIs can we provide you to accomplish your goals? Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] GUIDs?
If the since_id api calls will work against this, it might be a solution... On 26 March 2010 20:58, Donny V. don...@gmail.com wrote: Why don't you just use GUIDs as your id and then just add a timedate attribute stamp and call it a day. That would give you a unique id and also give your tweets an order. To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
To those voicing concerns about since_id I believe the key word is that they will no longer be *sequential*, something entirely different from them no longer being *increasing*. Since ID is a core part of the Twitter API that I very much doubt will be in jeopardy from this change. Twitter devs feel free to back me up or refute me. :) On Mar 26, 4:41 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, It's no secret that Twitter is growing exponentially. The tweets keep coming with ever increasing velocity, thanks in large part to your great applications. Twitter has adapted to the increasing number of tweets in ways that have affected you in the past: We moved from 32 bit unsigned integers to 64-bit unsigned integers for status IDs some time ago. You all weathered that storm with ease. The tweetapoclypse was averted, and the tweets kept flowing. Now we're reaching the scalability limit of our current tweet ID generation scheme. Unlike the previous tweet ID migrations, the solution to the current issue is significantly different. However, in most cases the new approach we will take will not result in any noticeable differences to you the developer or your users. We are planning to replace our current sequential tweet ID generation routine with a simple, more scalable solution. IDs will still be 64-bit unsigned integers. However, this new solution is no longer guaranteed to generate sequential IDs. Instead IDs will be derived based on time: the most significant bits being sourced from a timestamp and the least significant bits will be effectively random. Please don't depend on the exact format of the ID. As our infrastructure needs evolve, we might need to tweak the generation algorithm again. If you've been trying to divine meaning from status IDs aside from their role as a primary key, you won't be able to anymore. Likewise for usage of IDs in mathematical operations -- for instance, subtracting two status IDs to determine the number of tweets in between will no longer be possible. For the majority of applications we think this scheme switch will be a non-event. Before implementing these changes, we'd like to know if your applications currently depend on the sequential nature of IDs. Do you depend on the density of the tweet sequence being constant? Are you trying to analyze the IDs as anything other than opaque, ordered identifiers? Aside for guaranteed sequential tweet ID ordering, what APIs can we provide you to accomplish your goals? Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] GUIDs?
UUIDs are 128 bit integers. Moving from 64 to 128 bits is likely far more disruptive than the proposed scheme. ---Mark http://twitter.com/mccv On Fri, Mar 26, 2010 at 2:01 PM, Nigel Legg nigel.l...@gmail.com wrote: If the since_id api calls will work against this, it might be a solution... On 26 March 2010 20:58, Donny V. don...@gmail.com wrote: Why don't you just use GUIDs as your id and then just add a timedate attribute stamp and call it a day. That would give you a unique id and also give your tweets an order. To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Developer Preview: upcoming geo features (a.k.a A place is not just a latitude and a longitude - it has a name)
good stuff raffi, any further news on if/when the new place data
will be exposed via the Search API?
cheers, bob
GeoMeme - http://www.geome.me - what's happening where?
On Mar 2, 12:44 pm, Raffi Krikorian ra...@twitter.com wrote:
hi all.
i wanted to give you all a heads up on some big changes we're making to our
geo-tagging API. right now, you can post a status update along with a
latitude and longitude pair -- what we've jokingly referred to as
geo-tweeting, is actually just a status update with a where in the form
of a coordinate attached to it. we're about to add a whole new layer of
context to that status update.
our goal is to provide a few more options to API developers (and the users
they are servicing) through this contextual information. people, we find,
inherently want to talk about a place. a place, for a lot of people, has
a name and is not a latitude and longitude pair. (37.78215, -122.40060),
for example, doesn't mean a lot to a lot of people -- but, San Francisco,
CA, USA does. we're also trying to help users who aren't comfortable
annotating their tweets with their exact coordinates, but, instead, are
really happy to say what city, or even neighborhood, they are in.
annotating your place with a name does that too.
once our new additions to our geo infrastructure comes into place,
geo-tweets will get richer data. for example, a status object may look like
the following (abbreviated):
{
id:9505317221,
...
coordinates: {
type:Point,
coordinates: [-122.40060, 37.78215]
},
place: {
country:United States,
country_code:US,
full_name:SoMa, San Francisco,
name:SoMa,
place_type:neighborhood,
bounding_box: {
type:Polygon,
coordinates: [
[
[ -122.42284884, 37.76893497 ],
[ -122.3964, 37.76893497 ],
[ -122.3964, 37.78752897 ],
[ -122.42284884, 37.78752897 ]
]
]
},
id:7695dd2ec2f86f2b,
url:/1/geo/id/7695dd2ec2f86f2b.json
},
...
text:Wherever you go, there you are.
}
here you'll see a new place attribute that gives the contextual location of
the geo-tweet itself. in these cases, you'll have rich, and human-readable,
information about where this tweet has come from -- in this case, SoMa, San
Francisco. the geo object, for the time being, is still there, so you don't
have to worry about backwards compatibility. it will soon be deprecated,
however and please plan for that. we're also introducing a
coordinatesobject which has the added bonus that, when in JSON, it is
properly GeoJSON
encoded with the longitude before latitude.
to support this these changes we've added a few endpoints:
https://apiwiki.twitter.com/Twitter-REST-API-Method%3A-GET-geo-revers...https://apiwiki.twitter.com/Twitter-REST-API-Method%3A-GET-geo-ID
you can call geo/reverse_geocode with a latitude and longitude, and it will
return an array of places that you can use to annotate your tweet with.
each place that is returned will have a unique ID that you can use, as well
as a displayable name, and even a geographical bounding box that you can use
for display on a map. if you want more details, then hit the
geo/idendpoint where, if available, and if you're interested, you can
retrieve a
more detailed geometry for more accurate map drawing. we've also updated
the statuses/update documentation
(https://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses%C2%A0...)
to indicate how to pass that place ID with your status update.
for this first pass, we're only going live with United States-centric data,
but that will quickly be expanded geographically as we work out the kinks in
our system. there are definitely some nuances that i'm missing in this
e-mail, a few things are still in flux, but we're rapidly documenting this
on our wiki, and we hope to be going live with it quite soon. as always, if
you have any questions, just find us at @twitterapi, or drop us an e-mail.
--
Raffi Krikorian
Twitter Platform Teamhttp://twitter.com/raffi
To unsubscribe from this group, send email to
twitter-development-talk+unsubscribegooglegroups.com or reply to this email
with the words REMOVE ME as the subject.
Re: [twitter-dev] Re: Error 500 messages
I've had very slow responses to API calls today, but all seems to be working. On 26 March 2010 20:47, Cory cory.imdi...@gmail.com wrote: I think that was it, it's been much better now. I was worried because I'm in the middle of development and I thought I broke something! On Mar 25, 11:41 pm, John Kalucki j...@twitter.com wrote: Do these errors coincide with this incident? http://status.twitter.com/post/473971477/high-error-rate-and-page-loa... We threw a lot of 500s during this hour, and the 500s been slightly elevated from baseline since that issue was largely resolved. Ops is grinding down that error rate as I type. -John Kaluckihttp://twitter.com/jkalucki Infrastructure, Twitter Inc. On Thu, Mar 25, 2010 at 8:42 PM, Cory cory.imdi...@gmail.com wrote: I'm getting a bunch of Error 500 messages from different API calls today - is anyone else experiencing this? It isn't every call, but it's a good 1/3 of them. Sometimes a call will succeed, sometimes it will fail. The method being called doesn't seem to make a difference. I'm using oAuth, not sure if that matters. To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
Especially on mobile devices, it's significantly faster to sort tweets by comparing the long long representation of an ID rather than by the date. It's also more accurate, as two tweets that come in at the exact same second will still be sorted in the correct order. Steve On Mar 26, 4:41 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, It's no secret that Twitter is growing exponentially. The tweets keep coming with ever increasing velocity, thanks in large part to your great applications. Twitter has adapted to the increasing number of tweets in ways that have affected you in the past: We moved from 32 bit unsigned integers to 64-bit unsigned integers for status IDs some time ago. You all weathered that storm with ease. The tweetapoclypse was averted, and the tweets kept flowing. Now we're reaching the scalability limit of our current tweet ID generation scheme. Unlike the previous tweet ID migrations, the solution to the current issue is significantly different. However, in most cases the new approach we will take will not result in any noticeable differences to you the developer or your users. We are planning to replace our current sequential tweet ID generation routine with a simple, more scalable solution. IDs will still be 64-bit unsigned integers. However, this new solution is no longer guaranteed to generate sequential IDs. Instead IDs will be derived based on time: the most significant bits being sourced from a timestamp and the least significant bits will be effectively random. Please don't depend on the exact format of the ID. As our infrastructure needs evolve, we might need to tweak the generation algorithm again. If you've been trying to divine meaning from status IDs aside from their role as a primary key, you won't be able to anymore. Likewise for usage of IDs in mathematical operations -- for instance, subtracting two status IDs to determine the number of tweets in between will no longer be possible. For the majority of applications we think this scheme switch will be a non-event. Before implementing these changes, we'd like to know if your applications currently depend on the sequential nature of IDs. Do you depend on the density of the tweet sequence being constant? Are you trying to analyze the IDs as anything other than opaque, ordered identifiers? Aside for guaranteed sequential tweet ID ordering, what APIs can we provide you to accomplish your goals? Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
Can we assume a status ID will be unique or not? It's unclear here. If not, it should be a big problem for most apps. - Satoshi On Mar 27, 5:41 am, Taylor Singletary taylorsinglet...@twitter.com wrote: If you've been trying to divine meaning from status IDs aside from their role as a primary key, you won't be able to anymore. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
I would think that this would make no difference for since_id. The purpose of since_id is for us to the API give me the data I need that's happened since this id. Don't assume it's implemented as select * from tweets were id since_id. :) On Mar 26, 4:01 pm, Michael Bleigh mble...@gmail.com wrote: To those voicing concerns about since_id I believe the key word is that they will no longer be *sequential*, something entirely different from them no longer being *increasing*. Since ID is a core part of the Twitter API that I very much doubt will be in jeopardy from this change. Twitter devs feel free to back me up or refute me. :) On Mar 26, 4:41 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, It's no secret that Twitter is growing exponentially. The tweets keep coming with ever increasing velocity, thanks in large part to your great applications. Twitter has adapted to the increasing number of tweets in ways that have affected you in the past: We moved from 32 bit unsigned integers to 64-bit unsigned integers for status IDs some time ago. You all weathered that storm with ease. The tweetapoclypse was averted, and the tweets kept flowing. Now we're reaching the scalability limit of our current tweet ID generation scheme. Unlike the previous tweet ID migrations, the solution to the current issue is significantly different. However, in most cases the new approach we will take will not result in any noticeable differences to you the developer or your users. We are planning to replace our current sequential tweet ID generation routine with a simple, more scalable solution. IDs will still be 64-bit unsigned integers. However, this new solution is no longer guaranteed to generate sequential IDs. Instead IDs will be derived based on time: the most significant bits being sourced from a timestamp and the least significant bits will be effectively random. Please don't depend on the exact format of the ID. As our infrastructure needs evolve, we might need to tweak the generation algorithm again. If you've been trying to divine meaning from status IDs aside from their role as a primary key, you won't be able to anymore. Likewise for usage of IDs in mathematical operations -- for instance, subtracting two status IDs to determine the number of tweets in between will no longer be possible. For the majority of applications we think this scheme switch will be a non-event. Before implementing these changes, we'd like to know if your applications currently depend on the sequential nature of IDs. Do you depend on the density of the tweet sequence being constant? Are you trying to analyze the IDs as anything other than opaque, ordered identifiers? Aside for guaranteed sequential tweet ID ordering, what APIs can we provide you to accomplish your goals? Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Re: Developer Preview: upcoming geo features (a.k.a A place is not just a latitude and a longitude - it has a name)
hi bob.
soon :P
On Fri, Mar 26, 2010 at 2:06 PM, bob.hitching b...@hitching.net wrote:
good stuff raffi, any further news on if/when the new place data
will be exposed via the Search API?
cheers, bob
GeoMeme - http://www.geome.me - what's happening where?
On Mar 2, 12:44 pm, Raffi Krikorian ra...@twitter.com wrote:
hi all.
i wanted to give you all a heads up on some big changes we're making to
our
geo-tagging API. right now, you can post a status update along with a
latitude and longitude pair -- what we've jokingly referred to as
geo-tweeting, is actually just a status update with a where in the
form
of a coordinate attached to it. we're about to add a whole new layer of
context to that status update.
our goal is to provide a few more options to API developers (and the
users
they are servicing) through this contextual information. people, we
find,
inherently want to talk about a place. a place, for a lot of people,
has
a name and is not a latitude and longitude pair. (37.78215, -122.40060),
for example, doesn't mean a lot to a lot of people -- but, San
Francisco,
CA, USA does. we're also trying to help users who aren't comfortable
annotating their tweets with their exact coordinates, but, instead, are
really happy to say what city, or even neighborhood, they are in.
annotating your place with a name does that too.
once our new additions to our geo infrastructure comes into place,
geo-tweets will get richer data. for example, a status object may look
like
the following (abbreviated):
{
id:9505317221,
...
coordinates: {
type:Point,
coordinates: [-122.40060, 37.78215]
},
place: {
country:United States,
country_code:US,
full_name:SoMa, San Francisco,
name:SoMa,
place_type:neighborhood,
bounding_box: {
type:Polygon,
coordinates: [
[
[ -122.42284884, 37.76893497 ],
[ -122.3964, 37.76893497 ],
[ -122.3964, 37.78752897 ],
[ -122.42284884, 37.78752897 ]
]
]
},
id:7695dd2ec2f86f2b,
url:/1/geo/id/7695dd2ec2f86f2b.json
},
...
text:Wherever you go, there you are.
}
here you'll see a new place attribute that gives the contextual location
of
the geo-tweet itself. in these cases, you'll have rich, and
human-readable,
information about where this tweet has come from -- in this case, SoMa,
San
Francisco. the geo object, for the time being, is still there, so you
don't
have to worry about backwards compatibility. it will soon be deprecated,
however and please plan for that. we're also introducing a
coordinatesobject which has the added bonus that, when in JSON, it is
properly GeoJSON
encoded with the longitude before latitude.
to support this these changes we've added a few endpoints:
https://apiwiki.twitter.com/Twitter-REST-API-Method%3A-GET-geo-revers...https://apiwiki.twitter.com/Twitter-REST-API-Method%3A-GET-geo-ID
you can call geo/reverse_geocode with a latitude and longitude, and it
will
return an array of places that you can use to annotate your tweet with.
each place that is returned will have a unique ID that you can use, as
well
as a displayable name, and even a geographical bounding box that you can
use
for display on a map. if you want more details, then hit the
geo/idendpoint where, if available, and if you're interested, you can
retrieve a
more detailed geometry for more accurate map drawing. we've also updated
the statuses/update documentation (
https://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses%C2%A0...)
to indicate how to pass that place ID with your status update.
for this first pass, we're only going live with United States-centric
data,
but that will quickly be expanded geographically as we work out the kinks
in
our system. there are definitely some nuances that i'm missing in this
e-mail, a few things are still in flux, but we're rapidly documenting
this
on our wiki, and we hope to be going live with it quite soon. as always,
if
you have any questions, just find us at @twitterapi, or drop us an
e-mail.
--
Raffi Krikorian
Twitter Platform Teamhttp://twitter.com/raffi
To unsubscribe from this group, send email to twitter-development-talk+
unsubscribegooglegroups.com or reply to this email with the words REMOVE
ME as the subject.
--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi
To unsubscribe from this group, send email to
twitter-development-talk+unsubscribegooglegroups.com or reply to this email
with the words REMOVE ME as the subject.
Re: [twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
I hope you're right, but my app design depends on since_id, and before I proceed further I want to be sure that I will not have to rebuild when this new format comes in. On 26 March 2010 21:09, Ray Krueger raykrue...@gmail.com wrote: I would think that this would make no difference for since_id. The purpose of since_id is for us to the API give me the data I need that's happened since this id. Don't assume it's implemented as select * from tweets were id since_id. :) On Mar 26, 4:01 pm, Michael Bleigh mble...@gmail.com wrote: To those voicing concerns about since_id I believe the key word is that they will no longer be *sequential*, something entirely different from them no longer being *increasing*. Since ID is a core part of the Twitter API that I very much doubt will be in jeopardy from this change. Twitter devs feel free to back me up or refute me. :) On Mar 26, 4:41 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, It's no secret that Twitter is growing exponentially. The tweets keep coming with ever increasing velocity, thanks in large part to your great applications. Twitter has adapted to the increasing number of tweets in ways that have affected you in the past: We moved from 32 bit unsigned integers to 64-bit unsigned integers for status IDs some time ago. You all weathered that storm with ease. The tweetapoclypse was averted, and the tweets kept flowing. Now we're reaching the scalability limit of our current tweet ID generation scheme. Unlike the previous tweet ID migrations, the solution to the current issue is significantly different. However, in most cases the new approach we will take will not result in any noticeable differences to you the developer or your users. We are planning to replace our current sequential tweet ID generation routine with a simple, more scalable solution. IDs will still be 64-bit unsigned integers. However, this new solution is no longer guaranteed to generate sequential IDs. Instead IDs will be derived based on time: the most significant bits being sourced from a timestamp and the least significant bits will be effectively random. Please don't depend on the exact format of the ID. As our infrastructure needs evolve, we might need to tweak the generation algorithm again. If you've been trying to divine meaning from status IDs aside from their role as a primary key, you won't be able to anymore. Likewise for usage of IDs in mathematical operations -- for instance, subtracting two status IDs to determine the number of tweets in between will no longer be possible. For the majority of applications we think this scheme switch will be a non-event. Before implementing these changes, we'd like to know if your applications currently depend on the sequential nature of IDs. Do you depend on the density of the tweet sequence being constant? Are you trying to analyze the IDs as anything other than opaque, ordered identifiers? Aside for guaranteed sequential tweet ID ordering, what APIs can we provide you to accomplish your goals? Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
A quick clarification for you all since there seems to be the most concern around using since_id as a parameter: since_id will work as well as it does today as a result of this change. Also, a reminder that the actual integer format of the tweet IDs will not be changing. They'll still be unsigned 64bit integers as they are today. Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Fri, Mar 26, 2010 at 1:41 PM, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, It's no secret that Twitter is growing exponentially. The tweets keep coming with ever increasing velocity, thanks in large part to your great applications. Twitter has adapted to the increasing number of tweets in ways that have affected you in the past: We moved from 32 bit unsigned integers to 64-bit unsigned integers for status IDs some time ago. You all weathered that storm with ease. The tweetapoclypse was averted, and the tweets kept flowing. Now we're reaching the scalability limit of our current tweet ID generation scheme. Unlike the previous tweet ID migrations, the solution to the current issue is significantly different. However, in most cases the new approach we will take will not result in any noticeable differences to you the developer or your users. We are planning to replace our current sequential tweet ID generation routine with a simple, more scalable solution. IDs will still be 64-bit unsigned integers. However, this new solution is no longer guaranteed to generate sequential IDs. Instead IDs will be derived based on time: the most significant bits being sourced from a timestamp and the least significant bits will be effectively random. Please don't depend on the exact format of the ID. As our infrastructure needs evolve, we might need to tweak the generation algorithm again. If you've been trying to divine meaning from status IDs aside from their role as a primary key, you won't be able to anymore. Likewise for usage of IDs in mathematical operations -- for instance, subtracting two status IDs to determine the number of tweets in between will no longer be possible. For the majority of applications we think this scheme switch will be a non-event. Before implementing these changes, we'd like to know if your applications currently depend on the sequential nature of IDs. Do you depend on the density of the tweet sequence being constant? Are you trying to analyze the IDs as anything other than opaque, ordered identifiers? Aside for guaranteed sequential tweet ID ordering, what APIs can we provide you to accomplish your goals? Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Upcoming changes to the way status IDs are sequenced
On 03/26/2010 01:41 PM, Taylor Singletary wrote: Hi Developers, [snip] For the majority of applications we think this scheme switch will be a non-event. Before implementing these changes, we'd like to know if your applications currently depend on the sequential nature of IDs. Do you depend on the density of the tweet sequence being constant? Are you trying to analyze the IDs as anything other than opaque, ordered identifiers? Aside for guaranteed sequential tweet ID ordering, what APIs can we provide you to accomplish your goals? I'm a mathematician. So yes, I *am* trying to analyze the IDs as other than identifiers. ;-) As long as the status ID generation algorithm is documented - how many bits are timestamp, how many bits are random, what the granularity of the timestamp is, how the Spritzer and Gardenhose sampling is done, etc. - I can do what I want to do without any API additions. -- M. Edward (Ed) Borasky borasky-research.net/m-edward-ed-borasky A mathematician is a device for turning coffee into theorems. ~ Paul Erdős To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
I am using since_id in my app to know when to stop paging on both the api search api. My code expects the id to be sequential. RT @jkalucki: Primary-Key-Density-Change-Pocalypse. Of total doom. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
So it would be cool if some way were provided for me to gauge tweet volumes at regular intervals (currently every 2 minutes). Take a look to Tweespeed http://www.tweespeed.com But with the change annonced, this site is dead at term ... pas...@tweespeed On Mar 26, 10:01 pm, jerememonteau m...@jmoe.com wrote: Whoops, accidentally just replied to author the first time...but... I build this little site about 9 months ago, depending on the monotonically increasing nature of tweet IDs : http://www.tweelocity.com This is a fun graph : http://tweelocity.com/chart/60/300/ So it would be cool if some way were provided for me to gauge tweet volumes at regular intervals (currently every 2 minutes). I also think it's super cool that the twitter team is even giving a heads up like this. On Mar 26, 1:41 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, It's no secret that Twitter is growing exponentially. The tweets keep coming with ever increasing velocity, thanks in large part to your great applications. Twitter has adapted to the increasing number of tweets in ways that have affected you in the past: We moved from 32 bit unsigned integers to 64-bit unsigned integers for status IDs some time ago. You all weathered that storm with ease. The tweetapoclypse was averted, and the tweets kept flowing. Now we're reaching the scalability limit of our current tweet ID generation scheme. Unlike the previous tweet ID migrations, the solution to the current issue is significantly different. However, in most cases the new approach we will take will not result in any noticeable differences to you the developer or your users. We are planning to replace our current sequential tweet ID generation routine with a simple, more scalable solution. IDs will still be 64-bit unsigned integers. However, this new solution is no longer guaranteed to generate sequential IDs. Instead IDs will be derived based on time: the most significant bits being sourced from a timestamp and the least significant bits will be effectively random. Please don't depend on the exact format of the ID. As our infrastructure needs evolve, we might need to tweak the generation algorithm again. If you've been trying to divine meaning from status IDs aside from their role as a primary key, you won't be able to anymore. Likewise for usage of IDs in mathematical operations -- for instance, subtracting two status IDs to determine the number of tweets in between will no longer be possible. For the majority of applications we think this scheme switch will be a non-event. Before implementing these changes, we'd like to know if your applications currently depend on the sequential nature of IDs. Do you depend on the density of the tweet sequence being constant? Are you trying to analyze the IDs as anything other than opaque, ordered identifiers? Aside for guaranteed sequential tweet ID ordering, what APIs can we provide you to accomplish your goals? Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
I am still a little unclear if we will be able to determine the correct since_id to pass to the api by always looking for the largest tweet id we have seen. It seems if two messages are posted at very close to same time, they may not be sequential since the bottom bits will be randomly generated and I will not be able to safely just always use the largest id I have seen as the since_id?? Correct me if I am confusing myself please. On Mar 26, 2010, at 5:33 PM, Taylor Singletary wrote: A quick clarification for you all since there seems to be the most concern around using since_id as a parameter: since_id will work as well as it does today as a result of this change. Also, a reminder that the actual integer format of the tweet IDs will not be changing. They'll still be unsigned 64bit integers as they are today. Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Fri, Mar 26, 2010 at 1:41 PM, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, It's no secret that Twitter is growing exponentially. The tweets keep coming with ever increasing velocity, thanks in large part to your great applications. Twitter has adapted to the increasing number of tweets in ways that have affected you in the past: We moved from 32 bit unsigned integers to 64-bit unsigned integers for status IDs some time ago. You all weathered that storm with ease. The tweetapoclypse was averted, and the tweets kept flowing. Now we're reaching the scalability limit of our current tweet ID generation scheme. Unlike the previous tweet ID migrations, the solution to the current issue is significantly different. However, in most cases the new approach we will take will not result in any noticeable differences to you the developer or your users. We are planning to replace our current sequential tweet ID generation routine with a simple, more scalable solution. IDs will still be 64-bit unsigned integers. However, this new solution is no longer guaranteed to generate sequential IDs. Instead IDs will be derived based on time: the most significant bits being sourced from a timestamp and the least significant bits will be effectively random. Please don't depend on the exact format of the ID. As our infrastructure needs evolve, we might need to tweak the generation algorithm again. If you've been trying to divine meaning from status IDs aside from their role as a primary key, you won't be able to anymore. Likewise for usage of IDs in mathematical operations -- for instance, subtracting two status IDs to determine the number of tweets in between will no longer be possible. For the majority of applications we think this scheme switch will be a non-event. Before implementing these changes, we'd like to know if your applications currently depend on the sequential nature of IDs. Do you depend on the density of the tweet sequence being constant? Are you trying to analyze the IDs as anything other than opaque, ordered identifiers? Aside for guaranteed sequential tweet ID ordering, what APIs can we provide you to accomplish your goals? Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] statuses/friends Not Found Error
If you us id then include it in your URL like: http://api.twitter.com/statuses/friends/coryimdieke.xml or use the parameter screen_name=coryimdieke. Abraham 2010/3/26 Cory cory.imdi...@gmail.com I'm trying to run a query to grab the friends of the currently logged in user, and no matter what I do I get a Not Found error. Here is the request I'm making: http://api.twitter.com/statuses/friends.xml?id=coryimdiekeoauth_consumer_key=oauth_nonce=oauth_signature_method=HMAC-SHA1oauth_timestamp= 1269635891oauth_token=oauth_version=1.0oauth_signature= Response: ?xml version=1.0 encoding=UTF-8? hash errorNot found/error request/statuses/friends.xml? id=coryimdiekeamp;oauth_consumer_key=amp;oauth_nonce=amp;oauth_signature_method=HMAC- SHA1amp;oauth_timestamp=1269635891amp;oauth_token=amp;oauth_version=1.0amp;oauth_signature=/ request /hash I get the same response for that method regardless of how I try to call it. XML format, JSON format, with or without an id, user_id, with the id in the methodname instead of a parameter, etc. Same thing every time. My other calls all work fine. I can get statuses, check rate limit, verify_credentials, etc no problem. I've been fighting with this all night and I'm running out of ideas! Anyone have any thoughts? To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Abraham Williams | Community Advocate | http://abrah.am TwitterOAuth | http://github.com/abraham/twitteroauth This email is: [ ] shareable [x] ask first [ ] private. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
+1 on IDs being increasing. Sequential doesn't matter to me. I don't actually trust passing since_id to Twitter and having them handle the limiting of my result list. I've gotten into trouble when that feature suddenly quit being recognized and my code wasn't defensive enough to double-check since_id. With that fear in mind, increasing IDs are a must. I'm assuming the direct message ID algorithm will remain unchanged? Thanks, ~Barry http://bjhess.com http://getHarvest.com To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] SSL problems using ASI!
You can open an issue for Twitter: http://code.google.com/p/twitter-api/issues/entry http://code.google.com/p/twitter-api/issues/entryHopefully they will fix it. Until then there is probably some configuration setting to stop verifying the SSL cert. Abraham 2010/3/26 c0olcast c0olc...@gmail.com Hey everyone, Got a few questions here. We are currently developing a twitter client and we are using ASIHTTPRequest to access twitter. We want to use SSL for our requests. It works most of the times but some times we get SSL cert errors. I read post saying that there were some servers that had their certs setup wrong, is this is true, or should I start looking into something different. To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Abraham Williams | Community Advocate | http://abrah.am TwitterOAuth | http://github.com/abraham/twitteroauth This email is: [ ] shareable [x] ask first [ ] private. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Re: JavaScript XAuth library ??????
I notice that the oath.net/code site does not mention any code for working with OAuth / XAuth in C++/Qt. Are there libraries available for this? Regards, Nigel. On 26 March 2010 19:18, tux_advocate_hpu tuxcod...@gmail.com wrote: from the OAuth.net page: http://oauth.net/code/ Scroll down and look for Javascript section. It links to this site: http://oauth.googlecode.com/svn/code/javascript/ I don't think this library sends the appropriate OAuth headers in the HTTP request. Or at least that isn't how I got it working. Instead, it sends all the appropriate stuff as HTTP request variables (either GET or POST, I cannot remember). It does perform the SHA1 stuff and makes the oauth_nonce and oauth_timestamp values for you. On Mar 26, 2:09 pm, mostafa farghaly keepon...@gmail.com wrote: Hi guys i can't wrap my head around OAuth/XAuth for browserless apps is there any JavaScript Library for easy working with XAuth To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: GUIDs?
Yeah but its a permanent solution. On Mar 26, 5:06 pm, Mark McBride mmcbr...@twitter.com wrote: UUIDs are 128 bit integers. Moving from 64 to 128 bits is likely far more disruptive than the proposed scheme. ---Mark http://twitter.com/mccv On Fri, Mar 26, 2010 at 2:01 PM, Nigel Legg nigel.l...@gmail.com wrote: If the since_id api calls will work against this, it might be a solution... On 26 March 2010 20:58, Donny V. don...@gmail.com wrote: Why don't you just use GUIDs as your id and then just add a timedate attribute stamp and call it a day. That would give you a unique id and also give your tweets an order. To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: GUIDs?
I'm sorry this was meant for this post. http://groups.google.com/group/twitter-development-talk/browse_thread/thread/5152a34a8ae6ccb6 On Mar 26, 4:58 pm, Donny V. don...@gmail.com wrote: Why don't you just use GUIDs as your id and then just add a timedate attribute stamp and call it a day. That would give you a unique id and also give your tweets an order. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
Hi, From a practical development point of view having growing IDs are very helpful. With many common database operations greatly simplifies things for the developers. (Most application with local storage or cache need one key less. Or complex queries need fewer values in a temporary table.) This leads to more simple code and faster applications. I believe that your approach, the most significant bits being sourced from a timestamp, solves most problem and poses no need of change in code for most developer IF newer status messages always have bigger IDs. But I think a second precision should be enough. There is one other thing I worry about, even if there is second precision. When a user posts two status updates within a second. In this case the second one should alway have a bigger id. This seems a bit theoretical, but: - updates can come from a buffer eg. possible offline twitter client - updates longer than 140 characters can be split into two (or more) updates by a possible application. So newer updates from the same users should always have bigger IDs. If these two are granted, no application (except a few twitter statistics sites) should have any problem with a change like this. Benedek Toth On márc. 26, 21:41, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, It's no secret that Twitter is growing exponentially. The tweets keep coming with ever increasing velocity, thanks in large part to your great applications. Twitter has adapted to the increasing number of tweets in ways that have affected you in the past: We moved from 32 bit unsigned integers to 64-bit unsigned integers for status IDs some time ago. You all weathered that storm with ease. The tweetapoclypse was averted, and the tweets kept flowing. Now we're reaching the scalability limit of our current tweet ID generation scheme. Unlike the previous tweet ID migrations, the solution to the current issue is significantly different. However, in most cases the new approach we will take will not result in any noticeable differences to you the developer or your users. We are planning to replace our current sequential tweet ID generation routine with a simple, more scalable solution. IDs will still be 64-bit unsigned integers. However, this new solution is no longer guaranteed to generate sequential IDs. Instead IDs will be derived based on time: the most significant bits being sourced from a timestamp and the least significant bits will be effectively random. Please don't depend on the exact format of the ID. As our infrastructure needs evolve, we might need to tweak the generation algorithm again. If you've been trying to divine meaning from status IDs aside from their role as a primary key, you won't be able to anymore. Likewise for usage of IDs in mathematical operations -- for instance, subtracting two status IDs to determine the number of tweets in between will no longer be possible. For the majority of applications we think this scheme switch will be a non-event. Before implementing these changes, we'd like to know if your applications currently depend on the sequential nature of IDs. Do you depend on the density of the tweet sequence being constant? Are you trying to analyze the IDs as anything other than opaque, ordered identifiers? Aside for guaranteed sequential tweet ID ordering, what APIs can we provide you to accomplish your goals? Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: statuses/friends Not Found Error
Same for both :/ ?xml version=1.0 encoding=UTF-8? hash errorNot found/error request/statuses/friends/coryimdieke.xml? oauth_consumer_key=amp;oauth_nonce=amp;oauth_signature_method=HMAC- SHA1amp;oauth_timestamp=1269642081amp;oauth_token=amp;oauth_version=1.0amp;oauth_signature=/ request /hash I appreciate the help though - any other thoughts? Cory On Mar 26, 3:19 pm, Abraham Williams 4bra...@gmail.com wrote: If you us id then include it in your URL like:http://api.twitter.com/statuses/friends/coryimdieke.xmlor use the parameter screen_name=coryimdieke. Abraham 2010/3/26 Cory cory.imdi...@gmail.com I'm trying to run a query to grab the friends of the currently logged in user, and no matter what I do I get a Not Found error. Here is the request I'm making: http://api.twitter.com/statuses/friends.xml?id=coryimdiekeoauth_cons... 1269635891oauth_token=oauth_version=1.0oauth_signature= Response: ?xml version=1.0 encoding=UTF-8? hash errorNot found/error request/statuses/friends.xml? id=coryimdiekeamp;oauth_consumer_key=amp;oauth_nonce=amp;oauth_s ignature_method=HMAC- SHA1amp;oauth_timestamp=1269635891amp;oauth_token=amp;oauth_version= 1.0amp;oauth_signature=/ request /hash I get the same response for that method regardless of how I try to call it. XML format, JSON format, with or without an id, user_id, with the id in the methodname instead of a parameter, etc. Same thing every time. My other calls all work fine. I can get statuses, check rate limit, verify_credentials, etc no problem. I've been fighting with this all night and I'm running out of ideas! Anyone have any thoughts? To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Abraham Williams | Community Advocate |http://abrah.am TwitterOAuth |http://github.com/abraham/twitteroauth This email is: [ ] shareable [x] ask first [ ] private. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Re: statuses/friends Not Found Error
You are missing the API version. http://api.twitter.com*/1/* statuses/friends/coryimdieke.xml Abraham On Fri, Mar 26, 2010 at 15:23, Cory cory.imdi...@gmail.com wrote: Same for both :/ ?xml version=1.0 encoding=UTF-8? hash errorNot found/error request/statuses/friends/coryimdieke.xml? oauth_consumer_key=amp;oauth_nonce=amp;oauth_signature_method=HMAC- SHA1amp;oauth_timestamp=1269642081amp;oauth_token=amp;oauth_version=1.0amp;oauth_signature=/ request /hash I appreciate the help though - any other thoughts? Cory On Mar 26, 3:19 pm, Abraham Williams 4bra...@gmail.com wrote: If you us id then include it in your URL like: http://api.twitter.com/statuses/friends/coryimdieke.xmlor use the parameter screen_name=coryimdieke. Abraham 2010/3/26 Cory cory.imdi...@gmail.com I'm trying to run a query to grab the friends of the currently logged in user, and no matter what I do I get a Not Found error. Here is the request I'm making: http://api.twitter.com/statuses/friends.xml?id=coryimdiekeoauth_cons. .. 1269635891oauth_token=oauth_version=1.0oauth_signature= Response: ?xml version=1.0 encoding=UTF-8? hash errorNot found/error request/statuses/friends.xml? id=coryimdiekeamp;oauth_consumer_key=amp;oauth_nonce=amp;oauth_s ignature_method=HMAC- SHA1amp;oauth_timestamp=1269635891amp;oauth_token=amp;oauth_version= 1.0amp;oauth_signature=/ request /hash I get the same response for that method regardless of how I try to call it. XML format, JSON format, with or without an id, user_id, with the id in the methodname instead of a parameter, etc. Same thing every time. My other calls all work fine. I can get statuses, check rate limit, verify_credentials, etc no problem. I've been fighting with this all night and I'm running out of ideas! Anyone have any thoughts? To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Abraham Williams | Community Advocate |http://abrah.am TwitterOAuth |http://github.com/abraham/twitteroauth This email is: [ ] shareable [x] ask first [ ] private. To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Abraham Williams | Community Advocate | http://abrah.am Digri | Your network just got hotter | http://digri.net This email is: [ ] shareable [x] ask first [ ] private. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] the pushing speed for the Twitter's streaming API
You are probably getting limit messages when searching for those terms. The filter endpoints will return all tweets up to a predefined percentage of the total tweet stream. ---Mark http://twitter.com/mccv On Fri, Mar 26, 2010 at 3:49 PM, Lawrence lipeng...@gmail.com wrote: HI Everyone, I am wondering if there is a rate limiting for the pushing speed for the Twitter's streaming API? I first use the Twitter searching API to search a and it returns 2300 tweets per min to me. And then I tested o, it also returned me around 2400 tweets per min. Now, I tested track = a, b. Theoretically, the streaming API should returns me more than 4000 tweets per min. However, I found the streaming API still only returns me about 2400 tweets! My downloading speed is 16.68Mb/s So it seems that I still have enough spare bandwidth, but the Twitter just does not push more data to me. Is this true? Are there any internal limitation has been done by Twitter? Cheers Lawrence To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
So will they be monotonically increasing? That seems to be the key question. If they're not necessarily monotonic with respect to their date, then it seems like it would be a pretty painful change. Isaiah To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: the pushing speed for the Twitter's streaming API
Hi Mark, Thank you for your reply, but could you explain more? For example, if I search a very hot key word (not a, or o ), and the tweet flow is 5000 tweets/min. Does this mean that I only be able to receive 2000tweets/min because the restriction? what about the other 3000 tweets? Will they be delayed or just discarded? Cheers Lawrence On Mar 26, 3:57 pm, Mark McBride mmcbr...@twitter.com wrote: You are probably getting limit messages when searching for those terms. The filter endpoints will return all tweets up to a predefined percentage of the total tweet stream. ---Mark http://twitter.com/mccv On Fri, Mar 26, 2010 at 3:49 PM, Lawrence lipeng...@gmail.com wrote: HI Everyone, I am wondering if there is a rate limiting for the pushing speed for the Twitter's streaming API? I first use the Twitter searching API to search a and it returns 2300 tweets per min to me. And then I tested o, it also returned me around 2400 tweets per min. Now, I tested track = a, b. Theoretically, the streaming API should returns me more than 4000 tweets per min. However, I found the streaming API still only returns me about 2400 tweets! My downloading speed is 16.68Mb/s So it seems that I still have enough spare bandwidth, but the Twitter just does not push more data to me. Is this true? Are there any internal limitation has been done by Twitter? Cheers Lawrence To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
Hi Taylor (et al.), There are two reasons to think that, with the scheme you propose, tweet ids will not necessarily be monotonically increasing. Naveen hit the first: It seems if two messages are posted at very close to same time, they may not be sequential since the bottom bits will be randomly generated There is another: Time synchronization is hard to always get right (Einstein jokes aside). Clock skew happens for any number of reasons -- sometimes ntpd sends time backwards when network i/o gets really ugly, machine clocks wander, colos get out of sync, humans err, etc. These are rare events, but they do happen, and they can cause misalignment of clocks big enough for the odd tweet or two to fall through. Does missing the odd tweet or two matter? As for the tweet themselves: Probably not. But if it gets noticed, it causes users / developers to lose some amount of trust in their app / platform...and that matters a lot and can also generate a lot of annoying support emails. You wrote: since_id will work as well as it does today as a result of this change. Is that assuming monotonically increasing tweet ids? If not, would you mind elaborating? Having a universal counter is untenable, but having occasional, undiagnosable, unreproducible glitches also sucks. :) Thinking out loud, perhaps there is some middle ground -- a way to have generally monotonically increasing ids globally, and guaranteed monotonically increasing ids along some useful dimension, such as per user (this doesn't play nicely e.g. w/ Cassandra, but it is still reasonably scalable by other means). Not sure whether that would help folks or not... -josh To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Re: statuses/friends Not Found Error
Apparently not. It is however recommended to use https://api.twitter.com/1/for all calls except for the five oauth/* calls. Abraham On Fri, Mar 26, 2010 at 15:32, Cory cory.imdi...@gmail.com wrote: Huh, so you're right. All of my other calls work properly and they're all called using the same root URL - do some of them not need that? Thank you!! On Mar 26, 3:29 pm, Abraham Williams 4bra...@gmail.com wrote: You are missing the API version.http://api.twitter.com*/1/* statuses/friends/coryimdieke.xml Abraham On Fri, Mar 26, 2010 at 15:23, Cory cory.imdi...@gmail.com wrote: Same for both :/ ?xml version=1.0 encoding=UTF-8? hash errorNot found/error request/statuses/friends/coryimdieke.xml? oauth_consumer_key=amp;oauth_nonce=amp;oauth_signature_method=HMA C- SHA1amp;oauth_timestamp=1269642081amp;oauth_token=amp;oauth_version= 1.0amp;oauth_signature=/ request /hash I appreciate the help though - any other thoughts? Cory On Mar 26, 3:19 pm, Abraham Williams 4bra...@gmail.com wrote: If you us id then include it in your URL like: http://api.twitter.com/statuses/friends/coryimdieke.xmloruse the parameter screen_name=coryimdieke. Abraham 2010/3/26 Cory cory.imdi...@gmail.com I'm trying to run a query to grab the friends of the currently logged in user, and no matter what I do I get a Not Found error. Here is the request I'm making: http://api.twitter.com/statuses/friends.xml?id=coryimdiekeoauth_cons. .. 1269635891oauth_token=oauth_version=1.0oauth_signature= Response: ?xml version=1.0 encoding=UTF-8? hash errorNot found/error request/statuses/friends.xml? id=coryimdiekeamp;oauth_consumer_key=amp;oauth_nonce=amp;oauth_s ignature_method=HMAC- SHA1amp;oauth_timestamp=1269635891amp;oauth_token=amp;oauth_version= 1.0amp;oauth_signature=/ request /hash I get the same response for that method regardless of how I try to call it. XML format, JSON format, with or without an id, user_id, with the id in the methodname instead of a parameter, etc. Same thing every time. My other calls all work fine. I can get statuses, check rate limit, verify_credentials, etc no problem. I've been fighting with this all night and I'm running out of ideas! Anyone have any thoughts? To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Abraham Williams | Community Advocate |http://abrah.am TwitterOAuth |http://github.com/abraham/twitteroauth This email is: [ ] shareable [x] ask first [ ] private. To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Abraham Williams | Community Advocate |http://abrah.am Digri | Your network just got hotter |http://digri.net This email is: [ ] shareable [x] ask first [ ] private. To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Abraham Williams | Community Advocate | http://abrah.am Digri | Your network just got hotter | http://digri.net This email is: [ ] shareable [x] ask first [ ] private. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
Hi- Thanks for the heads-up. I have a couple of questions: Most importantly: when will this change happen? I understand that we should not depend on the format of the ID, but since we currently do, can we get more exact information on the new format? Is there going to be a very large discontinuous jump at the switchover time? Which bits will be used for what? We currently depend on the ID for a variety of caching and storage schemes -- I'm ok changing, but I need to plan, and understand the exact ID format post change to figure out how much work I need to. Thanks, -- David On Mar 26, 1:41 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, ... Please don't depend on the exact format of the ID. As our infrastructure needs evolve, we might need to tweak the generation algorithm again. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
On Mar 26, 4:01 pm, Josh Bleecher Snyder joshar...@gmail.com wrote: Having a universal counter is untenable, but having occasional, undiagnosable, unreproducible glitches also sucks. :) Thinking out loud, perhaps there is some middle ground -- a way to have generally monotonically increasing ids globally, and guaranteed monotonically increasing ids along some useful dimension, such as per user (this doesn't play nicely e.g. w/ Cassandra, but it is still reasonably scalable by other means). Not sure whether that would help folks or not... I used to work at Goddard Space Flight Center. As you can well imagine, accurate timekeeping was a hard requirement for many of the projects and tasks there, though not all of them. The issue is cost. Truly accurate timekeeping is achievable, but the cost to Twitter must be passed on to its customers, and the last time I looked, social media was an extremely competitive business. So I think we need to allow Twitter some leeway here. Right now, tweets carry a timestamp good to the nearest second. I haven't looked recently, but the last published figure from Twitter was that about 600 of them would have that timestamp on average. If you truly need time resolution finer than that, make a business case, apply for Firehose access, establish a business relationship with Twitter, invest in the infrastructure on your end for the high- precision timekeeping hardware and software, etc. As far as occasional glitches are concerned, we have those now. Every so often, we still get Fail Whales, 5xx errors, DDos attacks, etc. My broadband sometimes doesn't work. Sometimes, we have a windstorm or an ice storm and I lose electricity for a couple of hours. GMail goes down sometimes. Amazon goes down sometimes. Water mains break. And every so often, the astronomers add leap seconds to correct for hitches in the Earth's gitalong. I think we can live with an occasional clock error, or gap in the tweet IDs. And if you're interested, I can point you at the fairly simple math needed to correct for these glitches. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Re: the pushing speed for the Twitter's streaming API
They will be discarded. It is very unlikely that any single track term will put you over the limit however. ---Mark http://twitter.com/mccv On Fri, Mar 26, 2010 at 4:17 PM, Lawrence lipeng...@gmail.com wrote: Hi Mark, Thank you for your reply, but could you explain more? For example, if I search a very hot key word (not a, or o ), and the tweet flow is 5000 tweets/min. Does this mean that I only be able to receive 2000tweets/min because the restriction? what about the other 3000 tweets? Will they be delayed or just discarded? Cheers Lawrence On Mar 26, 3:57 pm, Mark McBride mmcbr...@twitter.com wrote: You are probably getting limit messages when searching for those terms. The filter endpoints will return all tweets up to a predefined percentage of the total tweet stream. ---Mark http://twitter.com/mccv On Fri, Mar 26, 2010 at 3:49 PM, Lawrence lipeng...@gmail.com wrote: HI Everyone, I am wondering if there is a rate limiting for the pushing speed for the Twitter's streaming API? I first use the Twitter searching API to search a and it returns 2300 tweets per min to me. And then I tested o, it also returned me around 2400 tweets per min. Now, I tested track = a, b. Theoretically, the streaming API should returns me more than 4000 tweets per min. However, I found the streaming API still only returns me about 2400 tweets! My downloading speed is 16.68Mb/s So it seems that I still have enough spare bandwidth, but the Twitter just does not push more data to me. Is this true? Are there any internal limitation has been done by Twitter? Cheers Lawrence To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Re: Search API from:username performance issues?
Hi Doug, I'm getting reports of this from:user delay happening again, so here are some relevant request/response headers and screengrabs of the results. There are some cases where it can be out of sync for up to 8-10 minutes. This is for the search query from:resourcefulmom Request Headers Host: search.twitter.com User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.17) Gecko/2009122115 Firefox/3.0.17 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://search.twitter.com/ Cookie: __utma=43838368.580929392773971800.1239516392.1262479801.1267595157.514; __utmz=43838368.1267595157.514.159.utmcsr=push.ly|utmccn=(referral)|utmcmd=referral|utmcct=/home; __utmv=43838368.lang%3A%20en; __utma=110314503.2301945900846264600.1239516535.1262063897.1269652388.170; __utmz=110314503.1258388229.140.5.utmcsr=twitter.com|utmccn=(referral)|utmcmd=referral|utmcct=/; rpp=100; __qca=1239588110-79825009-53773698; lang=all; _twitter_sess=BAh7DToMY3NyZl9pZCIlZDY4ZTY2YjI5ZDRkODgxOGM2ZWZlMWUxM2Y2MDA5%250AYzQ6DnJldHVybl90byJeaHR0cDovL3R3aXR0ZXIuY29tL29hdXRoL2F1dGhv%250Acml6ZT9vYXV0aF90b2tlbj1CbTB6c1YwZGgxTGdRWXNIcGJjNG94bnV0SnRN%250AdzJXRG1nMUVXclR4ekU6E3Bhc3N3b3JkX3Rva2VuIi00OWU2MGRhMDdhZDBk%250AZWNlNzJjNGUwNjlkNjJhYmYyN2E5NmFhYzc4Ogl1c2VyaQNUOWUiCmZsYXNo%250ASUM6J0FjdGlvbkNvbnRyb2xsZXI6OkZsYXNoOjpGbGFzaEhhc2h7AAY6CkB1%250Ac2VkewA6B2lkIiU3YTlmZjBlY2EzNTc2MTczMGZlNTFmMjYxZTJiZWJmZDoP%250AY3JlYXRlZF9hdGwrCH0QjyInAToRdHJhbnNfcHJvbXB0MA%253D%253D--265270e77f05570f78d081813c118b21eee077b9; __utmc=43838368; __utmb=110314503.1.10.1269652388; __utmc=110314503 Response Headers Date: Sat, 27 Mar 2010 01:13:06 GMT Server: hi Status: 200 OK X-Served-From: b022 X-Runtime: 2.41047 Content-Type: text/html; charset=utf-8 X-Served-By: c070.twitter.com X-Timeline-Cache-Hit: Miss Cache-Control: max-age=15, must-revalidate, max-age=300 Expires: Sat, 27 Mar 2010 01:18:03 GMT Content-Encoding: gzip Content-Length: 16677 Vary: Accept-Encoding X-Varnish: 3015348245 Age: 0 Via: 1.1 varnish X-Cache-Svr: c070.twitter.com X-Cache: MISS Set-Cookie: rpp=100; path=/; expires=Sun, 27 Mar 2011 01:13:03 GMT lang=all; path=/; expires=Sun, 27 Mar 2011 01:13:03 GMT Connection: close Screengrab of Twitter Search results: http://grab.by/3ln7 Screengrab of Twitter profile page: http://grab.by/3ln8 Please let me know if you need more info to help debug. Thanks, -Chad On Mon, Mar 15, 2010 at 2:55 PM, twitterdoug dc...@twitter.com wrote: Hi Chad, I didn't get there in time, the results looked fine to me. Should you be able to reproduce this, could you please send more information? dumps of results would be most useful, with complete HTTP requests/ responses... best, doug On Mar 12, 6:22 pm, Chad Etzel jazzyc...@gmail.com wrote: Hi dev team, I've gotten progressively more complaints from TweetGrid users about searches in the form of from:username not updating in a timely fashion. I haven't changed my code in a while, so after investigating it appears that the search index does lag behind a bit for from: searches as compared to just keywords. Is this a bug, or intentional? Example (if you read this in time):http://twitter.com/resourcefulmom compared tohttp://search.twitter.com/search?q=from:resourcefulmom Thanks, -Chad To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
Good morning hope all are well, Like TweeSpeed and also assumingly http://popacular.com/gigatweet/ I have to little apps deriving the volume of tweets on twitter from the ID http://twopular.com/labs/tweetMania http://twopular.com/labs/countingTweets With the announced change visualization of the twitter hype like this wouldn't be possible anymore. I think it would be great if you could provide some other means to track the volume of tweets before the change of the status_id take place. When is this change supposed to happen? Thx martin To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Search by Client
On Sat, Mar 27, 2010 at 12:56 AM, M. Edward (Ed) Borasky zzn...@gmail.comwrote: I posted some of the results from this to my blog. A few people have questioned the high position of UberTwitter, which is Blackberry-only. As has been noted on this list, when a person uses the built-in retweet, the *original* posting client is the one that shows up, not the one the retweeter used. Could that account for the high ranking of UberTwitter? Do retweets appear in the stream? My hunch is no, but I may not have observed long enough. If they do, then your hypothesis is quite likely true.. since UberTwitter is used by a number of celebrities (in my own limited observations). -- Harshad RJ http://hrj.wikidot.com To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Re: Error 500 messages
The same happened with me too...I thought I messed up something somewhere.. Ne way, hope to see better Twitter API response in the future. On Sat, Mar 27, 2010 at 2:17 AM, Cory cory.imdi...@gmail.com wrote: I think that was it, it's been much better now. I was worried because I'm in the middle of development and I thought I broke something! On Mar 25, 11:41 pm, John Kalucki j...@twitter.com wrote: Do these errors coincide with this incident? http://status.twitter.com/post/473971477/high-error-rate-and-page-loa... We threw a lot of 500s during this hour, and the 500s been slightly elevated from baseline since that issue was largely resolved. Ops is grinding down that error rate as I type. -John Kaluckihttp://twitter.com/jkalucki Infrastructure, Twitter Inc. On Thu, Mar 25, 2010 at 8:42 PM, Cory cory.imdi...@gmail.com wrote: I'm getting a bunch of Error 500 messages from different API calls today - is anyone else experiencing this? It isn't every call, but it's a good 1/3 of them. Sometimes a call will succeed, sometimes it will fail. The method being called doesn't seem to make a difference. I'm using oAuth, not sure if that matters. To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Thanks Regards Rajiv Verma Bangalore E-Mail: rajiv@gmail.com Ph: +91-92430-12766 Go Green, Use minimum natural resources! To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Search by Client
On 03/26/2010 08:14 PM, Harshad RJ wrote: On Sat, Mar 27, 2010 at 12:56 AM, M. Edward (Ed) Borasky zzn...@gmail.comwrote: I posted some of the results from this to my blog. A few people have questioned the high position of UberTwitter, which is Blackberry-only. As has been noted on this list, when a person uses the built-in retweet, the *original* posting client is the one that shows up, not the one the retweeter used. Could that account for the high ranking of UberTwitter? Do retweets appear in the stream? My hunch is no, but I may not have observed long enough. If they do, then your hypothesis is quite likely true.. since UberTwitter is used by a number of celebrities (in my own limited observations). The Sample streams I've looked at *do* contain retweets. If a tweet is a re-tweet created with the built-in retweet button, it has an embedded retweeted_status object, which is the original tweet. I haven't looked to see if the source value is copied from the original tweet into the retweet. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
My Desktop Client is also depending on since_id right now in order to display the user all new tweets since he logged out. Also without since_id and max_id it's not really possible to implemente a more link at the bottom. Personally, for my needs it would be enough if since_id and max_id would be replaced with since_date and max_date, as that wouldn't affect my application since I'm not relying on the tweet ids but only need to retrieve tweets in a specific timespan. But one thing for sure, there needs to be a replacement. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
