Fetching user_timeline on twitter
I have some basic questions (I am still learning this world) regarding fetching another user's timeline... 1. If basic authentication is a must to get the feed for protected updates, then does that mean that a third party website that purports to fetch a user's timeline needs to store the user's id and password to repeatedly provide these parameters as part of basic auth while fetching the timeline? Is that what sites such as friendfeed do? Or is there a way to perform a one time login and then somehow use a user specific credential on a long term basis? 2. When twitter moves to using oauth, will there be a way for other friend networks to continuously be able to fetch a twitter user's feed after first time Oauth based authorization by using the user specific token on a long-term basis? Naveen
Re: Fetching user_timeline on twitter
Hi Doug, The second part of your response was very encouraging so I just wanted to confirm it again :-) Are you saying Yes to how twitter's Oauth implementation will work? or are you saying It would be nice to be able to do it and therefore hope that twitter would do so? If it is the former, can you shed some light on how a third party website will be able to get long term user-specific credentials from twitter? Best and thnx Naveen On Feb 2, 9:31 pm, dougw igu...@gmail.com wrote: Naveen, Storing user credentials is never ideal but with basic auth, applications that want to make occasional calls to the API must retain a local copy of the credentials. Each request to a credential- protected API method requires credentials for authentication. Obviously this is not ideal, but the current API model is session- less. Your second question is yes. It will be nice, won't it? @dougw On Feb 2, 11:52 am, Naveen naveen.s.sax...@gmail.com wrote: I have some basic questions (I am still learning this world) regarding fetching another user's timeline... 1. If basic authentication is a must to get the feed for protected updates, then does that mean that a third party website that purports to fetch a user's timeline needs to store the user's id and password to repeatedly provide these parameters as part of basic auth while fetching the timeline? Is that what sites such as friendfeed do? Or is there a way to perform a one time login and then somehow use a user specific credential on a long term basis? 2. When twitter moves to using oauth, will there be a way for other friend networks to continuously be able to fetch a twitter user's feed after first time Oauth based authorization by using the user specific token on a long-term basis? Naveen- Hide quoted text - - Show quoted text -
[twitter-dev] Re: New Dev + API Call Problems
You are right. They did break the api in last build. I have been testing their trunk code for some time now. Fun or working with unreleased code :-) -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of netdevinc.com Sent: Thursday, June 11, 2009 3:03 PM To: Twitter Development Talk Subject: [twitter-dev] Re: New Dev + API Call Problems I found out through the TweetSharp group that They had to make an update to their wrapper due to a change from twitter. On Jun 11, 1:30 pm, Naveen Kohli naveenko...@gmail.com wrote: The link that i posted, all samples are based on Tweetsharp. Yes, the response comes back as string and then API uses extension method to convert it to object type that you asked for. Are you using trunk code of Tweetsharp or stable released version. put the break point right here at this line. var twitterResponse = twitter.Request(); look at what is being returned Request method. You will find details of the error there. Or if your AsUsers() is returninn null. Then cast that string to error object. var twerror = resp.AsError(); MessageBox.Show(twerror.ErrorMessage()); This should give u what went wrong. Let me know if you need any help. On Thu, Jun 11, 2009 at 11:38 AM, netdevinc.com advertis...@netdevinc.comwrote: I am using TweetSharp to interface with the Rest API code IFluentTwitter twitter = GetAuthenticatedRequest(); twitter.Users().GetFollowers().AsJson(); var twitterResponse = twitter.Request(); var myFollowers = twitterResponse.AsUsers(); /code twitterResponse looks like a text representation of my followers but when I try and cast the response AsUsers() myFollowers is null. So I could believe that it is a problem with the tweetsharp library, but I swear that I had this working yesterday afternoon! On Jun 11, 11:08 am, Naveen Kohli naveenko...@gmail.com wrote: Put a break point right after you send request to Twitter to get response and see what is being returned. I have a feeling that you are running into request rate limit. And the response you are getting back is not getting translated to your collection objects. Do you use any third party libraries to handle twitter request/response. Check out this link for examples... http://www.byteblocks.com/page/Twitter-Applications.aspx On Thu, Jun 11, 2009 at 10:57 AM, netdevinc.com advertis...@netdevinc.comwrote: I wanted to introduced myself to the community, say hi, and ask for help! I am a 10 year VB.NET developer and Air Force veteran. I have recently started learning C# / WPF / and some Tweet #! I started a quick wpf app yesterday and had two simple things working. Got a list of tweets by hashtag and a list of followers. I go to show the app today to a coworker and I no longer get a list of followers back? Where/how should I start debugging this? Is there a place to check the health of the API calls? Thanks for the help in advance! -- Naveen K Kohlihttp://www.netomatix.com
[twitter-dev] Re: Twitpocalypse Announcement
All Tweetshrap users, please update TwitterStatus object to use long for InReplyToStatusId property. Otherwise you will be getting overflow errors. -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of mozTom Sent: Friday, June 12, 2009 11:34 PM To: Twitter Development Talk Subject: [twitter-dev] Re: Twitpocalypse Announcement Dan, If you're using an unsigned integer, you won't see problems until the 4.2billionth tweet. If you're using a signed integer (which you don't need to, will there ever be NEGATIVE tweets?), you'll see it at the twitpocalypse. Thanks for playing. - Tom On Jun 12, 4:52 pm, Dan Udey d...@cdslash.net wrote: They're bumping it up so that if you're doing something silly (like using an unsigned integer to store the ID), you can find out and fix it. For an automatically incrementing ID, using a signed integer makes no sense, so this is a good chance for shortsighted developers to find and fix their bugs. An overflow will only happen if the developer of a given app has made a careless mistake. All Twitter is doing is triggering the event that will break careless developers' apps on a Friday, instead of breaking careless developers' apps on a Saturday. On Jun 12, 12:08 pm, J. Adam Moore jadammo...@gmail.com wrote: So do I just allocate as many bits as I can in my database to the id field and hope that it doesn't ever run out? I'm confused why you just announced that. Okay, so an overflow is happening. Is that your fault? Is this fixable on your end, my end. Is this just for people who are using 32-bit signed ints to store ids? Decide to do what? Roll it over like an odometer or increase the field size? Forgive me for being an idiot, but 'decide to do this' is just about vague enough to be insulting. I was happily under the assumption that this problem was considered long, long ago when the field size was initially chosen by who I also assumed to be smart people. On Jun 12, 10:23 am, Matt Sanford m...@twitter.com wrote: Hi all, The overflow of the 32-bit signed integer value for status ids (a.k.a The Twitpocalypse [1]) is fast approaching. The current estimate is around tomorrow at around 11am GMT, or 3:00am Pacific time in the case of Twitter. There is some discussion internally about accelerating things so we'll be in the office and able to cope. Nobody is their freshest at 3:00am, not to mention it would be nice to not have apps broken throughout the weekend if one-person developer teams don't notice. No decision has been made yet but I wanted to get something out to you all so you know what's going on in the event we decide to do this. Thanks; Matt Sanford / @mzsanford Twitter Dev [1] -http://www.twitpocalypse.com/
[twitter-dev] Bump Issue 949 - Deleting status returns error
Still waiting to get some kind of acknowledgment... http://code.google.com/p/twitter-api/issues/detail?id=949
[twitter-dev] Re: 200 errors
We are seeing this HTML META REFRESH as well from our clients. We are a mobile application and seeing this issue more and more frequently to the point that application is not functioning properly, its hard for use to provide any specific ip data as the carriers are most likely proxying the requests from the device. It is not limited to a specific api call either, it is a systemic issue across a wide range of calls we make. There was a ticket related to the issue in the bug tracker for search, but it has been closed and I think it should be re-opened as it is still a problem http://code.google.com/p/twitter-api/issues/detail?id=968 Any feedback would be appreciated. On Sep 6, 3:01 pm, Rich rhyl...@gmail.com wrote: Yeah it's happening to me again, same as my previous email, except the time stamp will be around 2 minutes ago On Sep 6, 4:05 pm, twittme_mobi nlupa...@googlemail.com wrote: Hi Ryan, I am getting the same error - i can found it in the logs of my app every day - at least 20 times. 1. The IP of the machine making requests to the Twitter API. If you're behind NAT, please be sure to send us your *external* IP. --- Name: twittme.mobi Address: 67.222.129.154 2. The IP address of the machine you're contacting in the Twitter cluster. You can find this on UNIX machines via the host or nslookup commands, and on Windows machines via the nslookup command. --- Name: twitter.com Address: 128.121.146.100 3. The Twitter API URL (method) you're requesting and any other details about the request (GET vs. POST, parameters, headers, etc.). --- 'account/rate_limit_status.xml' 4. Your host operating system, browser (including version), relevant cookies, and any other pertinent information about your environment. --- Linux, mobile browser,firefox, no cookies used. 5. What kind of network connection you have and from which provider, and what kind of network connectivity devices you're using. --- devices are mostly mobile..probably using mobile connections or wireless. Thanks! On Sep 5, 2:54 pm, Alex hyc...@gmail.com wrote: hi Ryan, any update on this issue ?
[twitter-dev] Re: Spammers in followers list
Its going to be hard to please everyone, if there is a delay when followers are actually being added to the list, then users will be confused or annoyed why the following numbers are out of sync. People generally expect realtime changes, especially on twitter where many people use it to have realtime conversations. People get annoyed when you make them wait 10 seconds let alone 24 hours. Ideally, twitter could update the cache of the users who the offending account was following.. Not saying its an easy solution, but twitter knows every account that the user was following and looping through those users to remove the spam account in theory would not be too difficult. Quick and dirty solution would be to just invalidate the cache for the users that who the spam account follows, but that would put extra load on their backend.. They do have some method of keeping the list realtime, as when valid users follow or un-follow it is pretty much instantaneous, it just a matter of doing the looping to unfollow everyone that the offending account follows using the existing code path. I am sure someone at twitter has already thought of this, but its not very high priority for them. Someone has to write the script for the abuse team to use to perform this action and I think the developers are probably pretty busy already.
[twitter-dev] Re: Bad response on Show
While this issue is known and does show up on the list fairly frequently, I think the best solution is to point users who report this to the number of existing issues filed for this bug so that they may STAR them and be kept up to date about what is going on with the issue. http://code.google.com/p/twitter-api/issues/detail?id=1014 http://code.google.com/p/twitter-api/issues/detail?id=1015 http://code.google.com/p/twitter-api/issues/detail?id=968 On Sep 8, 12:02 pm, JDG ghil...@gmail.com wrote: This is a very known issue and there are threads about it in this group once every 18 or so hours. On Tue, Sep 8, 2009 at 09:38, Francis Shanahan francisshana...@gmail.comwrote: I'm calling :http://twitter.com/users/show.xml My request works fine, it's signed correctly with a valid token etc. Every so often I get this response: !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/ TR/1999/REC-html401-19991224/strict.dtdhttp://www.w3.org/%0ATR/1999/REC-html401-19991224/strict.dtd !-- !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/TR/html4/strict.dtd; -- HTML HEAD META HTTP-EQUIV=Refresh CONTENT=0.1 META HTTP- EQUIV=Pragma CONTENT=no-cache META HTTP-EQUIV=Expires CONTENT=-1 TITLE/TITLE /HEAD BODYP/BODY /HTML No error is thrown and no reason code or anything comes back. Is this a bug on the Twitter side? Is this a known issue? -fs http://tweetarun.com -- Internets. Serious business.
[twitter-dev] Re: Random 408 errors having been appearing the last 48 hours
It might be useful if detailed (step by step) instructions of how to generate the debug information twitter needs to track down this HTTP data being returned on the API, I am not sure how much data you are getting but I would really like to provide as much as I possibly can and provide others with the tools to make providing this information as easily as possible. We unfortunately can't easily provide the necessary information as our application runs on a mobile device where we can not easily get the detailed information you require. I understand how to provide the ip address, and the verbose curl request.. Unclear what you are looking for when you are requesting a tcp dump.. I would be happy to attempt to generate this information if it will help expedite solving this problem.. On Sep 7, 10:06 pm, John Kalucki jkalu...@gmail.com wrote: If you are having connection problems like this, please send your IP address, account(s), a curl(1) -vvv trace, and a tcpdump of the failure to a...@twitter.com. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter inc. On Sep 7, 5:02 pm, fablau fabri...@virtualsheetmusic.com wrote: I am having the same issue, most of the times I cannot connect to Twitter, I get 408 error and the API is mostly unusable form my side. I am able to connect just a couple of times every 36-48 hours! Are we the only people having this issue? How that can be possible? Is there any way to contact Twitter folks about this issue? Are they aware of this? Any more thoughts and testimonials about this issue would be appreciated. Thank you for sharing. Best,
[twitter-dev] Re: Malformed JSON results
This sounds like the same issue many of us have been reporting where we get back HTML data instead of the expected JSON or XML response... I expect if you added logging to collect the raw response you would find it looks like the responses detailed in the tickets below... We get a similar parsing error from our app when this HTML response comes back from twitter. As you are also running on a mobile device it will be hard for you to generate the information twitter is requesting to correct this problem.. If you find a way to collect all the information they are asking for, please share it with us so that we can all provide as much data as they need. http://code.google.com/p/twitter-api/issues/detail?id=1014 http://code.google.com/p/twitter-api/issues/detail?id=1015 http://code.google.com/p/twitter-api/issues/detail?id=968 Twitter team has been asking for the IP address connection from, the account(s) used, a curl(1) -vvv trace, and a tcpdump of the failure to be sent to a...@twitter.com. --Naveen A. On Sep 9, 12:02 pm, Craig Hockenberry craig.hockenbe...@gmail.com wrote: We're seeing a weird error occur with the API in the past few days: every so often, users will get malformed JSON data. From our app, the following message is displayed: http://files.iconfactory.net/craig/bugs/TwitterYAJL.jpg That error occurs when the JSON data can't be parsed. I'd like to create an issue on Google Code, but this problem is extremely intermittent. Personally, I only saw it a few times when I was using the Search API. By the time I was able to debug the data being returned by the connection, the results had returned to normal. Without any debugging info, the problem felt like I was temporarily on a server that producing bad data. After a few refreshes, I found my way to a server that produced good data. I'd like to know if anyone else has been seeing malformed JSON or if there's any way to reliably reproduce the bad results. Thanks! -ch
[twitter-dev] Re: Random 408 errors having been appearing the last 48 hours
Thank John, I wish it were that simple, it does not happen as often when the request doesn't come from the Mobile Carriers servers.. Our client actually makes use of direct to twitter connections (thorugh mobile carrier) as well as proxied connections through our servers depending on the action being taken. The HTML data issue plagues requests made directly from the device but are much less frequent on requests we proxy through our servers. Every time I try to reproduce on the servers with curl and tcpdump, i have been unsuccessful in getting the bad data to come back. I apologize, I apparently put my initial response on the wrong thread, as I am referring to the HTML META-REFRESH issues with 200 responses that many have been seeing. --Naveen Ayyagari On Sep 9, 12:16 pm, John Kalucki jkalu...@gmail.com wrote: Point your mobile device through a web proxy that you control. Monitor the traffic there with tcpdump. On Sep 9, 7:07 am, Naveen A knig...@gmail.com wrote: It might be useful if detailed (step by step) instructions of how to generate the debug information twitter needs to track down this HTTP data being returned on the API, I am not sure how much data you are getting but I would really like to provide as much as I possibly can and provide others with the tools to make providing this information as easily as possible. We unfortunately can't easily provide the necessary information as our application runs on a mobile device where we can not easily get the detailed information you require. I understand how to provide the ip address, and the verbose curl request.. Unclear what you are looking for when you are requesting a tcp dump.. I would be happy to attempt to generate this information if it will help expedite solving this problem.. On Sep 7, 10:06 pm, John Kalucki jkalu...@gmail.com wrote: If you are having connection problems like this, please send your IP address, account(s), a curl(1) -vvv trace, and a tcpdump of the failure to a...@twitter.com. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter inc. On Sep 7, 5:02 pm, fablau fabri...@virtualsheetmusic.com wrote: I am having the same issue, most of the times I cannot connect to Twitter, I get 408 error and the API is mostly unusable form my side. I am able to connect just a couple of times every 36-48 hours! Are we the only people having this issue? How that can be possible? Is there any way to contact Twitter folks about this issue? Are they aware of this? Any more thoughts and testimonials about this issue would be appreciated. Thank you for sharing. Best,
[twitter-dev] 403 Forbidden on statuses/update.xml
Hello, Sorry I don't have full curl responses, but I haven't been able to reproduce via curl.. The below is from our logs as the response to a statuses/update.xml request. It looks like twitter is overloaded and is attempting to redirect to 503.html but permissions for that file are not set correctly so it is returning a 403 in response to the request.. This is happening fairly frequently right now when requests to post come through the server, but I am still working on reproducing with a curl output. httpRequest Failed - 403 - /statuses/update.xml !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title403 Forbidden/title /headbody h1Forbidden/h1 pYou don't have permission to access /503.html on this server./p /body/html
[twitter-dev] Re: non json response
Is there a specific way we can construct our request to mitigate the
non-json response? I have used a few different twitter clients on the
same mobile device and some of them do not seem to be plagued with the
bad data like we are? Does including something in the header help get
us through whatever filter is returning the bad data?
Maybe the Twitter cookies that are returned back on each request?
Currently, we don't pass them back on subsequent requests because they
shouldn't be necessary, but if it will make some of the bad JSON
responses go away, I'll spend the time to implement it..
These bad json responses have been a problem for over a month now and
while I realize it is a difficult problem to track down, the fact
remains that the API is not functioning correctly.
A response from the twitter team would be greatly appreciated.
On Sep 13, 6:01 am, Rudifa rudi.far...@gmail.com wrote:
I just had one non-json response, in the middle of about 10 requests
made with curl -vvv (other responses were correct)
Below are 3 requests and the non-json response bracketted by 2 good
responses which contain the response time and other logging data.
HTH
Rudi
rudolf-farkass-macbook-pro:TwitterWeb rudifarkas$ curl
-vvvhttp://twitter.com/users/show/rudifa.json
* About to connect() to twitter.com port 80 (#0)
* Trying 168.143.161.20... connected
* Connected to twitter.com (168.143.161.20) port 80 (#0) GET
/users/show/rudifa.json HTTP/1.1
User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3
OpenSSL/0.9.7l zlib/1.2.3
Host: twitter.com
Accept: */*
HTTP/1.1 200 OK
Date: Sun, 13 Sep 2009 09:45:23 GMT
Server: hi
X-RateLimit-Limit: 150
X-Transaction: 1252835123-2408-31139
Status: 200 OK
ETag: df090f6c8147e20ba7fe81315a66b9af
Last-Modified: Sun, 13 Sep 2009 09:45:23 GMT
X-RateLimit-Remaining: 124
Content-Type: application/json; charset=utf-8
Pragma: no-cache
Content-Length: 1176
Cache-Control: no-cache, no-store, must-revalidate, pre-check=0,
post-check=0
Expires: Tue, 31 Mar 1981 05:00:00 GMT
X-Revision: a62881015b2c2fb6f795bf931bd56bd494f37254
X-RateLimit-Reset: 1252836853
Set-Cookie: lang=en; path=/
Set-Cookie:
_twitter_sess=BAh7CDoRdHJhbnNfcHJvbXB0MDoHaWQiJWU5OGQyZmU3NWVkY2RhZjhkYTk5%
250ANTBlNTA4OTk0MzhhIgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFz
%250AaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsA--66931156c75554797fc576876bdec52dc705
736e;
domain=.twitter.com; path=/
Vary: Accept-Encoding
Connection: close
* Closing connection #0
{profile_sidebar_border_color:BDDCAD,description:Wrote firmware
for world-class osciloscopes for many years. Now learning iPhone
programming tricks. Loves
skiing.,url:null,screen_name:rudifa,status:
{in_reply_to_status_id:null,favorited:false,in_reply_to_user_id:null,
source:a
href=\http://apiwiki.twitter.com/\; rel=\nofollow\API/
a,created_at:Thu Sep 10 16:49:49 +
2009,in_reply_to_screen_name:null,id:
3890997267,truncated:false,text:De retour de la T\u00eate de
Parmelan},following:null,verified:false,profile_text_color:33,
followers_count:
9,profile_background_image_url:http://a1.twimg.com/
profile_background_images/17762518/
DSC01211-63-2.jpeg,created_at:Thu Apr 30 22:42:35 +
2009,notifications:null,friends_count:
29,profile_link_color:0084B4,profile_background_tile:false,favourite
s_count:
0,profile_background_color:9AE4E8,protected:false,time_zone:Bern,
location:Geneva,name:Rudi
Farkas,profile_sidebar_fill_color:DDFFCC,id:
36797542,statuses_count:52,utc_offset:
3600,profile_image_url:http://a1.twimg.com/profile_images/311858510/
me-bsp-6a_normal.png}
rudolf-farkass-macbook-pro:TwitterWeb rudifarkas$ curl
-vvvhttp://twitter.com/users/show/rudifa.json
* About to connect() to twitter.com port 80 (#0)
* Trying 168.143.161.20... connected
* Connected to twitter.com (168.143.161.20) port 80 (#0) GET
/users/show/rudifa.json HTTP/1.1
User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3
OpenSSL/0.9.7l zlib/1.2.3
Host: twitter.com
Accept: */*
HTTP/1.0 200 OK
Connection: Close
Pragma: no-cache
cache-control: no-cache
Refresh: 0.1
Content-Type: text/html; charset=iso-8859-1
!DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/
TR/1999/REC-html401-19991224/strict.dtd
!-- !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN
http://www.w3.org/TR/html4/strict.dtd; --
HTML
HEAD
META HTTP-EQUIV=Refresh CONTENT=0.1
META HTTP-EQUIV=Pragma CONTENT=no-cache
META HTTP-EQUIV=Expires CONTENT=-1
TITLE/TITLE
/HEAD
BODYP/BODY
/HTML
* Closing connection #0
rudolf-farkass-macbook-pro:TwitterWeb rudifarkas$ curl
-vvvhttp://twitter.com/users/show/rudifa.json
* About to connect() to twitter.com port 80 (#0)
* Trying 168.143.161.20... connected
* Connected to twitter.com (168.143.161.20) port 80 (#0) GET
/users/show/rudifa.json HTTP/1.1
User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3
OpenSSL/0.9.7l zlib/1.2.3
[twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names)
How does one keep a list up to date for a client without the concept of since_id, like we have for the timeline methods? I look at a lists as just a different timeline (granted one filtered to specific users), but that is how I would expect to view them in a client. From my understanding of cursors, on each request we have to start at -1 (to start paging) and page until we find an id that we already have locally. While this will work, it has a high probability of always over requesting data.. So if I have a list with two people in it, and they only tweet once a week, when I poll for updates of this list (say every 30min) the data is going to be the same most of the time(last 100 messages that these two people post). This seems like a waste of bandwidth for Twitter and us.. Some may argue that bandwidth is cheap, but it really is not on mobile devices. Some carriers charge per kb, but even on unlimited plans every byte transferred translates to additional battery drain.. Is there some concept of the cursor that I am not understanding that will allow us to also filter based on something like since_id? So we want to get messages newer than we already have and notify the user that the list has something new to display. Thanks to anyone who can clarify if I am misunderstanding something. --Naveen On Oct 28, 6:14 pm, Marcel Molina mar...@twitter.com wrote: Real soon now. We appreciate everyone's patience while we gradually ramp up traffic to lists to ensure we've got all our ducks in a row. On Wed, Oct 28, 2009 at 2:53 PM, Rich rhyl...@gmail.com wrote: +1 to this Any news on when the rest of us devs can get access to this to work on our apps? On Oct 28, 8:11 pm, Jesse Stay jesses...@gmail.com wrote: Maybe a little more appropriate to post this to a private list (no pun intended) for beta users? I admit I feel a little jealous every time I see one of these updates, unless there's some way to get into the beta. Thanks, Jesse On Wed, Oct 28, 2009 at 2:00 PM, Marcel Molina mar...@twitter.com wrote: Two additions and two changes to the List API will be deployed in the next few days: * List descriptions We're adding a description to every list. You'll be able to specify a description when you create or update a list and the description will be included in the payload. * Cursoring through lists of lists All resources that return a list of lists will include next and previous cursors and will accept a :cursor parameter. * Finding by list id rather than slug When you change the name of a list, the slug will be updated to reflect that change. That means using the slug in the url for resources to operate on lists requires the onerous task of validating that the slug for the list you are about to do something with hasn't been updated since the last time you stored its slug. What a nightmare :-) Every list also has an id. This value won't change. We'll be changing the API to replace all instances of a list slug in urls to be list ids instead. * Consistent names The terminology we've used thus far for people you follow with a list is members. The terminology for people who are following a list is subscribers. We're going to mirror the terminology used for users and change it to followers and following respectively. So: /:user/lists/:list_id/memberships becomes /:user/lists/:list_id/followers /:user/lists/:list_id/subscribers becomes /:user/lists/:list_id/following As we deploy these changes we'll send out a heads up on the dev list and @twitterapi. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio
[twitter-dev] Re: Developer Preview: Trends API
Looks very interesting. Something that pops to mind right away is maybe on the trends/ available accept a latitude and longitude to sort available trends by distance from a specific location (useful for mobile tweeters). It is unclear how many locations you plan to support but if the number is anything significant some method of searching/sorting through available trends will be extremely useful. --Naveen On Nov 9, 5:13 pm, Raffi Krikorian ra...@twitter.com wrote: We've heard from lots of users that trending topics, as seen on the twitter.com homepage and on search.twitter.com, are a fun way to figure out what's going on in the Twitter-verse at this very instant. The one feature request that we've heard over and over, however, is what's going on where I am?. To answer that, we wanted to give you all a heads up regarding the new Trends API that we're launching. This API will open up trending information that is specific to a number of locations around the world. At a high level, there will be two new endpoints: * an endpoint to give a listing of all locations that trends are available for, and * an endpoint to actually allow you to query by a specific location. We're using Yahoo!'s Where on Earth IDs (WOEIDs) to name each location that we have information for -- we're doing so because those IDs give not only language-agnostic, but also permanent, stable, and unique identifiers for geographic locations. For example, San Francisco has a permanent and unique WOEID of 2487956, London has 44418, and the Earth has WOEID 1. You can find out more about those IDs athttp://developer.yahoo.com/geo/geoplanet/ . The EXAMPLES section at the bottom of the documentation's landing page shows an example of how to find out the WOEID of a specific place. To start reading through the documentation, check out: https://twitterapi.pbworks.com/Twitter-REST-API-Method%3A-trends-avai...https://twitterapi.pbworks.com/Twitter-REST-API-Method%3A-trends-loca... It should be noted that at launch, unlike the trends that are available by the search API, these localized trends will not be rolled up into daily and weekly trends. Those rollups may come in a future release. -- Raffi Krikorian Twitter Platform Team ra...@twitter.com | @raffi
[twitter-dev] Re: List creation updated (needs description param)
We are seeing this issue as well.. We create a list with: http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-POST-lists This is returning all valid data with an id for the list, which indicates it was successfully created.. However when we try to get status for the list it is returning 404 Then we try to get the lists using http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-GET-lists And it is not returned in the result, the newly created list is also not on the twitter website.. however if we include the description parameter(with empty content) the list is created and returns expected data and does show up on the twitter website.. There is a bug here... The work around is to just include an empty description field, which should not break anything in the future either. On Nov 18, 8:08 pm, Marcel Molina mar...@twitter.com wrote: The description parameter is not required to create a list. On Wed, Nov 18, 2009 at 3:57 PM, David dch...@gmail.com wrote: I've been using the List api in my app, and just noticed that the POST method to /:user/lists.:format returned the correct response, but didn't actually create a list. I've been following this api document:http://apiwiki.twitter.com/Twitter-REST-API-Method:-POST-lists What I did notice was that the Add New List ui on Twitter.com has a description field, and so I tried the same call with an additional post param description, and it worked. The description param can be empty, but it is required to make this call work. Might be a bug? Just a heads up for anyone who might be wondering. DC -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio
[twitter-dev] Re: statuses/followers incorrectly ordered
This unorderedness is confusing to users.. They see their number of followers increase, then when they open their list of followers, the same set of people are always shown.. They are expecting to see their newest followers at the top of the list like they do on the twitter website. Its not even possible to to order this list ourselves, as the followed date is not available in the response. Though that would be a very expensive operation to do on a mobile device for people with thousands of followers. On Dec 2, 4:00 pm, Thomas Woolway tswool...@gmail.com wrote: Hi Wilhelm, Thanks for the follow up, The Twitter web site is still showing followers in the correct order - is this not something that can be extended to the API, and if not, why the disconnect? Thanks, Tom On Wed, Dec 2, 2009 at 7:32 PM, Wilhelm Bierbaum wilh...@twitter.comwrote: Your observations are correct. Ordering cannot be guaranteed because of the way we store the graph. I'll make sure that we update the documentation to reflect this fact. On Dec 2, 7:45 am, tom tswool...@gmail.com wrote: Hi All, We've recently seen a change in the ordering of the users that the statuses/followers method returns - according to the docs, this method should be returning the users in this order: They are ordered by the order in which they followed the user. However, they now appear essentially unordered - doing a simple curl call shows that we're not even getting the latest 100 users back. This is causing some problems in our app as we depend on the ordering being as documented. Has anyone else noticed this? Can anyone from Twitter confirm? Thanks, Tom
[twitter-dev] Re: Search API: new HTTP response codes for rate limiting starting 12/16
I would have to agree with mat. But to each their own. The return codes frequently make no sense from twitter, so i guess the fact that it doesn't make sense it is irrelevant, so long as it is consistent. On Dec 3, 6:29 pm, mat mat.st...@gmail.com wrote: Given that 400 is bad request, and the client SHOULD NOT repeat the request without modifications (w3.org's emphasis), and 503 means service unavailable, try again later, and can include a retry-after header, would it not have made more sense to change the response code of the REST API to the more correct one? On Dec 3, 10:41 pm, Wilhelm Bierbaum wilh...@twitter.com wrote: In an effort to simplify our APIs, we are standardizing the response codes returned by our various systems. Historically, the Search API has returned 503 for rate limiting whereas the REST API has returned 400. So, we are changing the response codes sent back from the Search API. Starting Wednesday, December 16th, 2009 the search API will respond with error code 400 in the event that the number of requests you have made exceeds the quota afforded by your rate limit. Please update your response handler accordingly. If you have any questions, please feel free to post them on twitter- development-talk.
[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: 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] Re: Upcoming changes to the way status IDs are sequenced
This was my initial concern with the randomly generated ids that I
brought up, though I think Brian described it better than I.
It simply seems very likely that when using since_id to populate newer
tweets for the user, that some tweets will never be seen, because the
since_id of the last message received will be larger than one
generated 1ms later.
With the random generation of ids, I can see two way guarantee
delivery of all tweets in a users timeline
1. Page forwards and backwards to ensure no tweets generated at or
near the same time as the newest one did not receive a lower id. This
will be very expensive for a mobile client not to mention complicate
any refresh algorithms significantly.
2. Given that we know how IDs are generated (i.e. which bits represent
the time) we can simply over request by decrementing the since_id time
bits, by a second or two and filter out duplicates. (again, not really
ideal for mobile clients where battery life is an issue, plus it then
makes the implementation very dependent on twitters id format
remaining stable)
Please anyone explain if Brian and I are misinterpreting this as a
very real possibility of never displaying some tweets in a time line,
without changing how we request data from twitter (i.e. since_id
doesn't break)
--Naveen Ayyagari
@knight9
@SocialScope
On Apr 8, 7:01 pm, Brian Smith br...@briansmith.org wrote:
What does “within the caveats given above” mean? Either since_id will work or
it won’t. It seems to me that if IDs are only in a “rough” order, since_id
won’t work—in particular, there is a possibility that paging through tweets
using since_id will completely skip over some tweets.
My concern is that, since tweets will not be serialized at the time they are
written, there will be a race condition between me making a request and users
posting new statuses. That is, I could get a response with the largest id in
the response being X that gets evaluated just before a tweet (X-1) has been
saved in the database; If so, when I issue a request with since_id=X, my
program will never see the newer tweet (X-1).
Are you going to change the implementation of the timeline methods so that
they never return a tweet with ID X until all nodes in the cluster guarantee
that they won’t create a new tweet with an ID less than X?
I implement the following logic:
1. Let LATEST start out as the earliest tweet available in the user’s
timeline.
2. Make a request with since_id={LATEST}, which returns a set of tweets
T.
3. If T is empty then stop.
4. Let LATEST= max({ id(t), for all t in T}).
5. Goto 2.
Will I be guaranteed not to skip over any tweets in the timeline using this
logic? If not, what do I need to do to ensure I get them all?
Thanks,
Brian
From: twitter-development-talk@googlegroups.com
[mailto:twitter-development-t...@googlegroups.com] On Behalf Of Mark McBride
Sent: Thursday, April 08, 2010 5:10 PM
To: twitter-development-talk@googlegroups.com
Subject: Re: [twitter-dev] Re: Upcoming changes to the way status IDs are
sequenced
Thank you for the feedback. It's great to hear about the variety of use
cases people have for the API, and in particular all the different ways
people are using IDs. To alleviate some of the concerns raised in this thread
we thought it would be useful to give more details about how we plan to
generate IDs
1) IDs are still 64-bit integers. This should minimize any migration pains.
2) You can still sort on ID. Within a few millieconds you may get out of
order results, but for most use cases this shouldn't be an issue.
3) since_id will still work (within the caveats given above).
4) We will provide a way to backfill from the streaming API.
5) You cannot use the generated ID to reverse engineer tweet velocity. Note
that you can still use the streaming API to determine the rate of public
statuses.
Additional items of interest
1) At some point we will likely start using this as an ID for direct messages
too
2) We will almost certainly open source the ID generation code, probably
before we actually cut over to using it.
3) We STRONGLY suggest that you treat IDs as roughly sorted (roughly being
within a few ms buckets), opaque 64-bit integers. We may need to change the
scheme again at some point in the future, and want to minimize migration
pains should we need to do this.
Hopefully this puts you more at ease with the changes we're making. If it
raises new concerns, please let us know!
---Mark
http://twitter.com/mccvhttp://twitter.com/mccv
On Mon, Apr 5, 2010 at 4:18 PM, M. Edward (Ed) Borasky zn...@comcast.net
wrote:
On 04/05/2010 12:55 AM, Tim Haines wrote:
This made me laugh. Hard.
On Fri, Apr 2, 2010 at 6:47 AM, Dewald Pretorius dpr...@gmail.com wrote:
Mark,
It's extremely important where you have two bots that reply to each
others' tweets. With incorrectly sorted tweets, you
[twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
Ahh, yes, your workaround is a little better than mine, but it is
still a work around and requires changes to how since_id is currently
used by what I have assume is most applications. I understand the need
for change and am willing to work around it, I can imagine the
scalability issues of trying to use a synchronized id for all tweets.
However, I wanted to be clear and feel it should be made obvious that
with this change, there is a possibility that a tweet may not be
delivered to client if the implementation of how since_id is currently
used is not updated to cover the case. I still envision the situation
as more likely than you seem to believe and figure as tweet velocity
increases, the likelihood will also increase; But I am assuming have
better data to support your viewpoint than I and shall defer.
--Naveen Ayyagari
@knight9
@SocialScope
On Apr 8, 7:37 pm, Mark McBride mmcbr...@twitter.com wrote:
It's a possibility, but by no means a probability. Note that you can
mitigate this by using the newest tweet that is outside your danger zone.
For example in a sequence of tweets t1, t2 ... ti ... tn with creation
times c1, c2 ... ci ... cn and a comfort threshold e you could use since_id
from the latest ti such that c1 - ci e.
---Mark
http://twitter.com/mccv
On Thu, Apr 8, 2010 at 4:27 PM, Naveen knig...@gmail.com wrote:
This was my initial concern with the randomly generated ids that I
brought up, though I think Brian described it better than I.
It simply seems very likely that when using since_id to populate newer
tweets for the user, that some tweets will never be seen, because the
since_id of the last message received will be larger than one
generated 1ms later.
With the random generation of ids, I can see two way guarantee
delivery of all tweets in a users timeline
1. Page forwards and backwards to ensure no tweets generated at or
near the same time as the newest one did not receive a lower id. This
will be very expensive for a mobile client not to mention complicate
any refresh algorithms significantly.
2. Given that we know how IDs are generated (i.e. which bits represent
the time) we can simply over request by decrementing the since_id time
bits, by a second or two and filter out duplicates. (again, not really
ideal for mobile clients where battery life is an issue, plus it then
makes the implementation very dependent on twitters id format
remaining stable)
Please anyone explain if Brian and I are misinterpreting this as a
very real possibility of never displaying some tweets in a time line,
without changing how we request data from twitter (i.e. since_id
doesn't break)
--Naveen Ayyagari
@knight9
@SocialScope
On Apr 8, 7:01 pm, Brian Smith br...@briansmith.org wrote:
What does “within the caveats given above” mean? Either since_id will
work or it won’t. It seems to me that if IDs are only in a “rough” order,
since_id won’t work—in particular, there is a possibility that paging
through tweets using since_id will completely skip over some tweets.
My concern is that, since tweets will not be serialized at the time they
are written, there will be a race condition between me making a request and
users posting new statuses. That is, I could get a response with the largest
id in the response being X that gets evaluated just before a tweet (X-1) has
been saved in the database; If so, when I issue a request with since_id=X,
my program will never see the newer tweet (X-1).
Are you going to change the implementation of the timeline methods so
that they never return a tweet with ID X until all nodes in the cluster
guarantee that they won’t create a new tweet with an ID less than X?
I implement the following logic:
1. Let LATEST start out as the earliest tweet available in the
user’s timeline.
2. Make a request with since_id={LATEST}, which returns a set of
tweets T.
3. If T is empty then stop.
4. Let LATEST= max({ id(t), for all t in T}).
5. Goto 2.
Will I be guaranteed not to skip over any tweets in the timeline using
this logic? If not, what do I need to do to ensure I get them all?
Thanks,
Brian
From: twitter-development-talk@googlegroups.com [mailto:
twitter-development-t...@googlegroups.com] On Behalf Of Mark McBride
Sent: Thursday, April 08, 2010 5:10 PM
To: twitter-development-talk@googlegroups.com
Subject: Re: [twitter-dev] Re: Upcoming changes to the way status IDs are
sequenced
Thank you for the feedback. It's great to hear about the variety of use
cases people have for the API, and in particular all the different ways
people are using IDs. To alleviate some of the concerns raised in this
thread we thought it would be useful to give more details about how we plan
to generate IDs
1) IDs are still 64-bit integers. This should minimize any migration
pains.
2) You can still sort on ID
[twitter-dev] Re: lang=en queries to search API not working
Also seems to happen with the geocode parameter, adding a since_id
makes the results return but we should not be able to that.
On Nov 29, 10:22 am, clichekiller clichekil...@gmail.com wrote:
This has been a problem for some time now, is nothing be done to
address it? The since fix isn't great because anything outside of
that five to six day window will not be returned.
On Nov 28, 5:23 am, MartinW wright.mar...@gmail.com wrote:
Hi Steve,
I've found the same problem over the past couple of days too. I had
also narrowed it down to the lang parameter but selecting all does
still not guarantee results.
This is now impacting my live site as no results are being returned.
I'm also going to investigate whether rate limiting could be the
issue.
Please let me know if you get any further with your investigations.
Cheers
Martin Wright
http://www.twitseek.com
On Nov 27, 3:42 am, steve ick...@gmail.com wrote:
This reproduces even onhttp://search.twitter.com. If you try to
filter to en only results you get back 0 items for most queries.
Select try all languages from the search portal or remove lang=en
from your API query and you get results for your queries (most of
which are in english.)
What's weird is this seemed to be working fine until about 2 days
ago. And its been very intermittent since. Yesterday queries would
work for a while then they would stop working (same query to the
API.) But today they seem to be broken for me all day. Other members
of my team reported the same issue yesterday so it defenitly seems to
be something on your end.
BTW... When calling the API and this happens we're getting back an
error similar to this:
jsonp1290717568994({results:[],max_id:7896158276488192,since_id:
7896158276488192,refresh_url:?
since_id=7896158276488192q=Thanksgiving,results_per_page:50,page:
1,completed_in:0.019352,warning:adjusted since_id to
7896158276488192 due to temporary
error,since_id_str:7896158276488192,max_id_str:7896158276488192,q
uery:Thanksgiving});
I did a search and this error was reported back in June but nobody
ever responded... Crossing my fingers that this message doesn't go
into the void as well...
--
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group:
http://groups.google.com/group/twitter-development-talk
[twitter-dev] Re: Twitter API Timeouts
We have been seeing this behavior as well since early yesterday. We have a lot of connections (a noticeable percentage) simply timeout. We have tested various timeouts and work arounds and it appears as though the connections will happily be kept open indefinitely with no response if there is no timeout set.. I am also curious if there was a change made that would be attributed to this change in behavior. --Naveen On Feb 28, 2:14 am, Colin Howe colintheh...@googlemail.com wrote: Hi, We've started seeing the API drop a lot of our requests. No error, no response at all. Is this a known issue or is it a change I should have been aware of? Cheers, Colin -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] Re: 401 unauthorized on blackberry after appending ;interface=wifi
There are two possible issue you are having.. Most likely you simply need to append the network transport AFTER all signatures have been generated. If you append it before, then those additional characters are being included in the signature but the BlackBerry does not actually send that part of the connection string to anyone, it is only used internally. Less likely but possible, the WIFI you are using is routing you redirecting to you a landing page to login to the WIFI access. --Naveen Ayyagari SocialScope On Apr 13, 12:41 pm, Mickey ng.mic...@gmail.com wrote: Hi On blackberry with httpConnection, I need to add network transport string such as ;interface=wifi to the url. The problem is, once I added the network transport string, I get 401 unauthorized for status update and GET statuses/user_timeline. If I remove the transport string, then I can POST updates and GET statuses everything runs fine. So it seems the request I'm sending to twitter api is correct. Is there anything special with the transport string that might cause problems? -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] Re: A new permission level
I had most of the same thoughts already mentioned in this thread so wont reiterate everyone, except to add that this seems like a rather sudden and disruptive change coming just after #devnestsf where Twitter made a point that it was trying to provide better guidance so companies that rely on the platform have time to plan and make changes. @knight9 -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
[twitter-dev] Android Twitter Account Manager
Hi!
I am developing an android application and want to integrate Twitter.
What I understand is if on user's device, official android Twitter app
is installed then we can authenticate using account manager.
AccountsByType is com.twitter.android.auth.login
and if not installed then show web page.
Is my understanding correct?
Now authenticating using twitter web login page is working fine.
But how do I login using account manager?
I got token and token secret using account manager from
•com.twitter.android.oauth.token
•com.twitter.android.oauth.token.secret
As I am using Twitter4J so I do following
AccessToken a = new AccessToken(token,secret);
Twitter twitter = new TwitterFactory().getInstance();
twitter.setOAuthConsumer(Constant.CONSUMER_KEY,
Constant.CONSUMER_SECRET);
twitter.setOAuthAccessToken(a);
try {
twitter.getAccountSettings();
User_Id = twitter.getScreenName();
return true;
} catch (TwitterException e) {
return false;
}
Authentication fails.
CONSUMER_KEY CONSUMER_SECRET are the keys I got when I registered
the app at twitter... but I dont understand how can I use these keys
with Official Android Twitter app authentication?
Pls. let me know
Thanks
--
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list
Change your membership to this group:
https://groups.google.com/forum/#!forum/twitter-development-talk
[twitter-dev] Too much twittering?
I have a user who posts a lot of messages and is reporting that his messages are not posting from our app. After some investigation when the user posts on twitter.com he receives a message something to the effect too much twittering for the hour... The API does not report any error message and just fails to post the message without an error message to the client. I believe this is a bug in the API. Has anyone else seen this? Thanks. --Naveen
[twitter-dev] Re: friend exist function not working!!!!
As far twitter API goes, it works fine.I implemented in C#. you can see it
here.
http://www.byteblocks.com/post/2009/05/22/Verify-if-two-twitter-users-are-friends.aspx
May be some JS guru can look thru code and suggest some change.
On Tue, Jun 9, 2009 at 6:16 AM, grand_unifier jijodasgu...@gmail.comwrote:
this has been bothering me for quite some tym now...i have written a
code which inputs two usernames(twitter id) n will o/p if both are
friends or not...
the api doc for thsi response is here...
http://apiwiki.twitter.com/Twitter-REST-API-Method:-friendships-exists
!-- this is the javascript json parser function --
script type=text/javascript src=../jquery-1.2.6.min.js
/script
script type=text/javascript
$(document).ready(function()
{
$('form#search').bind(submit, function(e)
{
e.preventDefault();
$('#content').html('');
var query1 = urlencode($('input[name=user_a]').val
()); //userA
var query2 = urlencode($('input
[name=user_b]').val()); //userB
$.ajax( {
url: 'http://twitter.com/
friendships/exists.json?user_a='+http://twitter.com/%0Afriendships/exists.json?user_a=%27+
query1 +
'user_b=' + query2,
dataType: jsonp,
success: function(data)
{
if(data ==
true)
{
var
newDiv = 'ptrue/p';
}
$('#content').append(newDiv);
}
});
});
})
function urlencode(str) {
return escape(str).replace(/\+/g,'%2B').replace(/%20/g,
'+').replace(/\*/g, '%2A').replace(/\//g, '%2F').replace(/@/g, '%40');
}
})
/script
!-- javascript ends here --
the json returns true or falsebut still it doesnt seem to work
can anyone refine the code???
--
Naveen K Kohli
http://www.netomatix.com
[twitter-dev] Re: New Dev + API Call Problems
Put a break point right after you send request to Twitter to get response and see what is being returned. I have a feeling that you are running into request rate limit. And the response you are getting back is not getting translated to your collection objects. Do you use any third party libraries to handle twitter request/response. Check out this link for examples... http://www.byteblocks.com/page/Twitter-Applications.aspx On Thu, Jun 11, 2009 at 10:57 AM, netdevinc.com advertis...@netdevinc.comwrote: I wanted to introduced myself to the community, say hi, and ask for help! I am a 10 year VB.NET developer and Air Force veteran. I have recently started learning C# / WPF / and some Tweet #! I started a quick wpf app yesterday and had two simple things working. Got a list of tweets by hashtag and a list of followers. I go to show the app today to a coworker and I no longer get a list of followers back? Where/how should I start debugging this? Is there a place to check the health of the API calls? Thanks for the help in advance!
[twitter-dev] Re: Twitter Developer/Founder Community on Ning - Registration Open
This has gone little too far. Somebody just floated an idea and it became a storm here :-) Guys lets just tweet :-) Somebody mentioned dumb ideas and things like that. I think there is nothing as dumb or stupid idea. Every great idea has to start from somewhere and then takes a shape. Just respect others initiative to propose something. You don't have to accept it or like it. If you don't like it, just suggest something constructive. Happy tweeting and happy friday yay .. its raining and its cold ... On Thu, Jun 11, 2009 at 4:06 PM, Bradley S. O'Hearne brad.ohea...@gmail.com wrote: Suggestion: one of you ask the other to marry them, and invite us all to the wedding, or otherwise let's kill this thread. Hint: why make an enemy out of a complete stranger, when you could instead speak (regardless of agreement / disagreement) with courtesy and make a friend, or a business associate. Just as easy to make a friend than an enemy. Cheers, Brad On Jun 11, 2009, at 8:38 AM, Mario Gooding wrote: So who do I contact with my web site ideas? On Thu, Jun 11, 2009 at 11:34 AM, Dossy Shiobara do...@panoptic.comwrote: On 6/11/09 9:27 AM, jstrellner wrote: If developers feel like they might get bashed for posting their ideas here, they wont post them here, which is fragmentation. If only this were true, then we should aggressively bash all the dumb ideas until this list's signal-to-noise ratio improves. Sadly, people will keep posting stupid ideas regardless of the bashing, so we have nothing to worry about. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- Naveen K Kohli http://www.netomatix.com
[twitter-dev] Re: Rate Limits - Am I Blacklisted?
There are two rate limits. One for user account and one for IP address. Since you mentioned that when you are on a different server, your status is 100. That definitely indicates that your shared server has lot of twitter API activity going on. On Tue, Jun 16, 2009 at 8:14 AM, betweeted i...@carterandcompanyllc.comwrote: I began noticing some strange behavior - 401 errors on status/update calls saying We were unable to authenticate you. I racked my brain, checked and rechecked the username and password, then finally I decided to create a small script to check my ratelimit at account/rate_limit_status.xml and sure enough, I was at 0. I waited an hour, and I was at 54. Within minutes, however, I was back to 0. So, naturally I thought some bot had hijacked my scripts and was eating up my api calls. I downloaded server logs. There is no excessive activity at all. In any case, all my calls are authenticated, so they should be using the users api limit, not my servers. On a hunch, I uploaded the same rate limit checking script to a different host that I have access to (with a different IP). Guess what? 100 hits remaining. In fact, whether I authenticate the request or not, I'm still at 0 hits remaining whenever I try that same script on my server. But, if I try it somewhere else, I have all 100. Am I blacklisted? -- Naveen K Kohli http://www.netomatix.com
[twitter-dev] Re: Search API to require HTTP Referrer and/or User Agent
Redefining HTTP spec, eh :-) Whatever makes twitter boat float. Lets hope for the best. Just concerned that some firewalls or proxies tend to remove referrer. On Tue, Jun 16, 2009 at 1:05 PM, Stuart stut...@gmail.com wrote: It's optional in the HTTP spec, but mandatory for the Twitter Search API. I don't see a problem with that. Doug: Presumably the body of the 403 response will contain a suitable descriptive error message in the usual format? -Stuart -- http://stut.net/projects/twitter 2009/6/16 Naveen Kohli naveenko...@gmail.com: Why would you make decision based on Referrer which is an OPTIONAL header field in HTTP protocol? Making decision based on something that is REQUIRED may be more appropriate. On Tue, Jun 16, 2009 at 12:33 PM, Doug Williams d...@twitter.com wrote: Hi all, The Search API will begin to require a valid HTTP Referrer, or at the very least, a meaningful and unique user agent with each request. Any request not including this information will be returned a 403 Forbidden response code by our web server. This change will be effective within the next few days, so please check your applications using the Search API and make any necessary code changes. Thanks, Doug -- Naveen K Kohli http://www.netomatix.com -- Naveen K Kohli http://www.netomatix.com
[twitter-dev] Re: DDoS Status Update
Chris , We implemented something like this network status using the rate_limit_status call (for the IP), while some of the numbers are sometimes wonky with this api right now we poll this every 5 minutes and set a flag to enable or disable all twitter requests from the server depending on what is returned. This has the effect of backing off twitter when we get limited, as well as automatically bring twitter service up when the blackout period subsides.. Even with the wonky numbers, we blindly accept what the call returns and disable when api credits say they are 0 and if the call times out you know for sure its time to back off. ( I know these criteria are overly aggressive, but we figure its better to aggressively back off in the hopes it helps things recover quicker) When the server is in blackout, simply report that twitter is still having ongoing issues to the user with a note and a link to the twitter status page, keeps them informed as to what is going on without flooding your inbox or you having to respond to all the users emails, If the message in the UI saves you from having to read through and answer 10 emails, it is worth the work to implement. Its all about keeping the user informed, just like we like to be informed by twitter about what the status is. Another tip is to make sure you set a resonable timeout for all your twitter requests or people get stuck waiting for your page to load and think its broken, better to timeout and again report that twitter is still recovering for DDoS attack and direct them to the twitter status page.. While this may seem like unnecessary work if twitter is going to get back to normal, it makes your app more robust to issues in the future, keeps your users better informed as to what is happening (without contacting you), and also helps reduce number of requests to twitter that they have to ignore while they are recovering On that note, it seems our servers are disabling significantly less frequently over the past few hours. Heres hoping it lasts.. Not sure if it was the back off or if Twitter has just managed to cope better with the traffic issues.. Doesn't really matter to me which.. Oh and thanks for the update Chad, it really is nice just to hear something, even if its not great news. On Aug 8, 2009, at 4:19 AM, Chris Babcock wrote: On Fri, 7 Aug 2009 11:05:32 -0700 Ryan Sarver rsar...@twitter.com wrote: I wanted to send everyone an update to let you know what has been happening, the known issues, some suggestions on how to resolve them and some idea of how to move forward. This was really appreciated. When the dust clears, maybe one more suggestion? An API to check on the network status? I think infrastucture attacks aren't going away anytime soon. We've got a diversity of applications here, some of which can chew up the bandwidth pretty well and some of those just don't make sense to run if other users can't get on-line. Instead of answering, Is it OK to restart my cron jobs? the cron jobs could shut themselves down for increments of so many hours. Chris Babcock PS - Of course it could be misused, but I think the benefit is net.
[twitter-dev] Re: How do I handle 302 redirects with curl?
Sometimes the rate_limit_status call is not returning a 302 to redirect, or the rate_limit_status xml, but HTML with a meta refresh in it (which curl doesnt understand to follow redirect/retry). Its not huge problem for us, but it can affect some throttling code people may or may not be implementing. (when you get this response, a subsequent retry request usually succeeds 95% of the time) Here is an example response I am talking about: curl http://twitter.com/account/rate_limit_status.xml -L -v * About to connect() to twitter.com port 80 (#0) * Trying 168.143.162.68... connected * Connected to twitter.com (168.143.162.68) port 80 (#0) GET /account/rate_limit_status.xml HTTP/1.1 User-Agent: curl/7.18.2 (x86_64-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.8 Host: twitter.com Accept: */* * HTTP 1.0, assume close after body HTTP/1.0 200 OK Connection: Close Pragma: no-cache cache-control: no-cache Refresh: 0.1 Content-Type: text/html; charset=iso-8859-1 !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/TR/1999/REC-html401-19991224/strict.dtd !-- !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/TR/html4/strict.dtd; -- HTML HEAD META HTTP-EQUIV=Refresh CONTENT=0.1 META HTTP-EQUIV=Pragma CONTENT=no-cache META HTTP-EQUIV=Expires CONTENT=-1 TITLE/TITLE /HEAD BODYP/BODY /HTML On Aug 8, 2009, at 11:20 AM, Chad Etzel wrote: Hmm, Unfortunately this 302 business will completely goof OAuth calls. If you are able to programmatically see that you are getting these redirects, try calling the account/rate_limit_status call [1] (it could be any call, but this one is free and is a GET). You should still get a 302 (I'm pretty sure). Then if you jump through the redirect hoops with this call, it should clear you from more 302's for a while. I'm out today, but if someone could try this and report back if it works that would be helpful. [1] http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-account%C2%A0rate_limit_status Thanks, -Chad On Sat, Aug 8, 2009 at 6:31 AM, timwhitlocktim.whitl...@publicreative.com wrote: I've seem the 302 Location headers having invalid URLs... i.e. two ? symbols. The original query string and then an additional ? for the token at the end. Following this redirect blindly has resulted in a Forbidden response. Also it is unclear whether the redirect location needs to be re- signed? (I am not doing so, but may explain the 403?) On Aug 8, 8:14 am, Rich rhyl...@gmail.com wrote: Excellent our client now supports the 302's :) On Aug 8, 7:37 am, Chad Etzel c...@twitter.com wrote: You may have to follow redirects more than once *wink wink nudge nudge* with curl you can add --location flag. There's a good bit of info in the man page as well. If using curl with PHP, you can set: curl_setopt($ch, CURLOPT_FOLLOWLOCATION, TRUE); HTH, -Chad On Sat, Aug 8, 2009 at 1:31 AM, TjLluo...@gmail.com wrote: All of my scripts check for Status 200 before proceeding. Now we are (sometimes) getting a 302, but when I try curl --netrc -s -D -http://twitter.com/account/rate_limit_status.xml Gave me a 302 with a Location of: http://twitter.com/account/rate_limit_status.xml?c73f7db0 but when I tried curl --netrc -s -D - 'http://twitter.com/account/rate_limit_status.xml?c73f7db0' it seemed to want to redirect me to http://twitter.com/account/rate_limit_status.xml If accepting 30x is a requirement now, I'd like some advice on how to do so. TjL
[twitter-dev] Re: How do I handle 302 redirects with curl?
I see this behavior 1/4 times I call rate_limit_status and I call rate_limit_status every 5 minutes.. On Aug 8, 2009, at 9:01 PM, CaMason wrote: To confirm, I am also seeing this behaviour. Some output I've received on numerous occasions this evening: -bash-3.2# curl --interface eth0 http://twitter.com/account/rate_limit_status.xml !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/ TR/1999/REC-html401-19991224/strict.dtd !-- !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/TR/html4/strict.dtd; -- HTML HEAD META HTTP-EQUIV=Refresh CONTENT=0.1 META HTTP-EQUIV=Pragma CONTENT=no-cache META HTTP-EQUIV=Expires CONTENT=-1 TITLE/TITLE /HEAD BODYP/BODY /HTML -Craig On Aug 8, 11:25 pm, Chad Etzel c...@twitter.com wrote: Hmm, it shouldn't be spitting back HTML. How often are you seeing this? -Chad On Sat, Aug 8, 2009 at 1:02 PM, Naveen Ayyagariknig...@gmail.com wrote: Sometimes the rate_limit_status call is not returning a 302 to redirect, or the rate_limit_status xml, but HTML with a meta refresh in it (which curl doesnt understand to follow redirect/retry). Its not huge problem for us, but it can affect some throttling code people may or may not be implementing. (when you get this response, a subsequent retry request usually succeeds 95% of the time) Here is an example response I am talking about: curlhttp://twitter.com/account/rate_limit_status.xml-L -v * About to connect() to twitter.com port 80 (#0) * Trying 168.143.162.68... connected * Connected to twitter.com (168.143.162.68) port 80 (#0) GET /account/rate_limit_status.xml HTTP/1.1 User-Agent: curl/7.18.2 (x86_64-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.8 Host: twitter.com Accept: */* * HTTP 1.0, assume close after body HTTP/1.0 200 OK Connection: Close Pragma: no-cache cache-control: no-cache Refresh: 0.1 Content-Type: text/html; charset=iso-8859-1 !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/TR/1999/REC-html401-19991224/strict.dtd !-- !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/TR/html4/strict.dtd; -- HTML HEAD META HTTP-EQUIV=Refresh CONTENT=0.1 META HTTP-EQUIV=Pragma CONTENT=no-cache META HTTP-EQUIV=Expires CONTENT=-1 TITLE/TITLE /HEAD BODYP/BODY /HTML On Aug 8, 2009, at 11:20 AM, Chad Etzel wrote: Hmm, Unfortunately this 302 business will completely goof OAuth calls. If you are able to programmatically see that you are getting these redirects, try calling the account/rate_limit_status call [1] (it could be any call, but this one is free and is a GET). You should still get a 302 (I'm pretty sure). Then if you jump through the redirect hoops with this call, it should clear you from more 302's for a while. I'm out today, but if someone could try this and report back if it works that would be helpful. [1]http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-account%C2%A0ra ... Thanks, -Chad On Sat, Aug 8, 2009 at 6:31 AM, timwhitlocktim.whitl...@publicreative.com wrote: I've seem the 302 Location headers having invalid URLs... i.e. two ? symbols. The original query string and then an additional ? for the token at the end. Following this redirect blindly has resulted in a Forbidden response. Also it is unclear whether the redirect location needs to be re- signed? (I am not doing so, but may explain the 403?) On Aug 8, 8:14 am, Rich rhyl...@gmail.com wrote: Excellent our client now supports the 302's :) On Aug 8, 7:37 am, Chad Etzel c...@twitter.com wrote: You may have to follow redirects more than once *wink wink nudge nudge* with curl you can add --location flag. There's a good bit of info in the man page as well. If using curl with PHP, you can set: curl_setopt($ch, CURLOPT_FOLLOWLOCATION, TRUE); HTH, -Chad On Sat, Aug 8, 2009 at 1:31 AM, TjLluo...@gmail.com wrote: All of my scripts check for Status 200 before proceeding. Now we are (sometimes) getting a 302, but when I try curl --netrc -s -D -http://twitter.com/account/rate_limit_status.xml Gave me a 302 with a Location of: http://twitter.com/account/rate_limit_status.xml?c73f7db0 but when I tried curl --netrc -s -D - 'http://twitter.com/account/rate_limit_status.xml?c73f7db0' it seemed to want to redirect me to http://twitter.com/account/rate_limit_status.xml If accepting 30x is a requirement now, I'd like some advice on how to do so. TjL
[twitter-dev] Re: Twitter Update, 8/9 10am PST
1. OAuth rarely works - I tried a number of your apps and it seems to work 1 out of 6-7 times. As a note, it worked better with Safari, but not every time. -Not applicable 2. 302 redirect - not sure anymore since our code has been updated to follow them automatically. 3. General request timeouts - still seeing it but, not sure if it when we get temp blacklisted. 4. HTML in responses Haven't seen it today actually, but was fairly frequent last night. 5. Unexpected rate limiting / blacklisting - less frequent, but still happening.
[twitter-dev] Re: Twitter Update, 8/9 noon PST
Most calls seem to be working much better for us.
in response to the rate_limit_status call, I get HTML back
occasionally.. looks like the fail whale page and 502 twitter over
capacity..
Got this one about 10 min ago.
08-09-09 19:40:15rate_limit_status response(502): !DOCTYPE html
PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
html xmlns=http://www.w3.org/1999/xhtml; lang=en xml:lang=en
head
meta http-equiv=Content-Type content=text/html;
charset=utf-8 /
meta http-equiv=Content-Language content=en-us /
titleTwitter / Over capacity/title
link rel=icon href=http://static.twitter.com/favicon.ico;
type=image/ico /
style type=text/css
body{background:#9AE4E8 url(http://static.twitter.com/images/
bg.gif) no-repeat fixed left top;color:#333;font:0.75em
Helvetica,Arial,sans-serif;text-align:center}
#container { width: 755px; margin: 0 auto; padding: 0px 0; text-
align: left; position: relative; }
#content { width: 100%; margin-top: 0px; float: left; padding-
bottom: 15px; background: transparent url(http://static.twitter.com/images/arr2.gif
) no-repeat scroll 25px 0px;}
.subpage #content .wrapper { background-color: #fff; padding:
20px 10px 15px 10px; -moz-border-radius: 5px;-webkit-border-radius:
5px;}
.subpage #content h1, .subpage #content h2, .subpage #content
h3, .subpage #content h4, .subpage #content h5 { margin: 3px 0pt 4px; }
.subpage #content p { line-height: 1.2; margin: 5px 0; }
.subpage #content ul { padding-left: 30px; }
.subpage #content ol, #side ol { padding-left: 30px; }
a{text-decoration:none;color: #0084b4;}
#content div.desc { margin: 11px 0px 10px 0px; }
a img{border:0;}
ul{list-style:square;padding-left:20px;}
#navigation { position: absolute; top: 12px; right: 0; padding:
0px 5px 0px 5px; line-height: 0.5em; text-align: center; }
#navigation ul {
list-style:none
margin: 0; padding: 0px;
width: auto; height: 100%;
}
#navigation li { display:inline; padding: 0 0 0 5px; }
#navigation li:before { content: ' '; padding-right: 0; }
#navigation li.first:before { content: ''; padding-right: 0; }
#navigation, #footer { background-color: #fff; -moz-border-
radius: 5px;-webkit-border-radius: 5px;}
#footer { clear: left; width: 555px; text-align: center; padding:
1px 0; line-height: 1; }
#footer li { display: inline; padding: 0 0 0 5px; }
#footer li.first:before { content: ''; padding-right: 0; }
/style
/head
body
div id=container class=subpage
div id=navigation
ul
li class=firsta href=http://twitter.com;Home/a/li
lia href=http://twitter.com/public_timeline;Public
Timeline/a/li
lia href=http://help.twitter.com;Help/a/li
/ul
/div
h1 id=headera href=http://twitter.com;img src=http://static.twitter.com/images/twitter_logo_s.gif
//a/h1
div id=content
div class=desc/div
div class=wrapper
span style=font-size:1.8em; font-weight:boldTwitter is
over capacity./spanbr /
div style=font-size:1.2em;margin-top:
2px;color:#b6b6a3Too many tweets! Please wait a moment and try
again./divbr /
p style=margin-bottom:10px;text-align:centerimg src=http://static.twitter.com/images/whale.png
//p
/div
/div
div id=footer style=width:100%
ul
li class=firstcopy; 2009 Twitter/li
lia href=/help/aboutusAbout Us/a/li
lia href=/help/contactContact/a/li
lia href=http://blog.twitter.com/;Blog/a/li
lia href=http://status.twitter.com/;Status/a/li
lia href=/help/apiAPI/a/li
lia href=http://help.twitter.com/;Help/a/li
lia href=/help/jobsJobs/a/li
lia href=/help/tosTOS/a/li
lia href=/help/privacyPrivacy/a/li
/ul
/div
/div
!-- BEGIN google analytics --
script type=text/javascript
var gaJsHost = ((https: == document.location.protocol) ? https://ssl
. : http://www.;);
document.write(unescape(%3Cscript src=' + gaJsHost + google-
analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E));
/script
script type=text/javascript
var pageTracker = _gat._getTracker(UA-30775-6);
pageTracker._setDomainName(twitter.com);
pageTracker._trackPageview('503 Error');
/script
!-- END google analytics --
/body
/html
On Aug 9, 2009, at 3:13 PM, Ryan Sarver wrote:
*Finally* have what we hope is good news for everyone. As of about
10 minutes ago we have been able to restore critical parts of API
operation that should have great affect on your apps. As such, most
of your apps should begin to function normally again. I have tested
a few OAuth apps and they seem to be working as expected.
Please test your apps from their standard configs to see what
results you get and
[twitter-dev] Twitter Update, 8/10 noon PST
Just wanted to report that we are back up and running for the most part as well, BUT quite a number of our servers are still experiencing some BlackOut periods where twitter fails to respond and connections time out. They seem to last about 5-10 minutes each. We are running quite a few servers during this time to mitigate the issue propagating to our users, but it is a costly proposition to continue running this many servers for extended periods of time. Here is a traceroute to twitter.com on one of the servers during the Blackout when it is not getting any response from twitter traceroute to twitter.com (168.143.162.100), 30 hops max, 40 byte packets 1 67-207-128-2.slicehost.net (67.207.128.2) 0.000 ms 0.000 ms 0.000 ms 2 209-20-79-2.slicehost.net (209.20.79.2) 0.000 ms 0.000 ms 0.000 ms 3 ge-6-10-193.car1.StLouis1.Level3.net (4.53.160.189) 0.000 ms 0.000 ms 0.000 ms 4 ae-11-11.car2.StLouis1.Level3.net (4.69.132.186) 0.000 ms 0.000 ms 0.000 ms 5 ae-4-4.ebr2.Chicago1.Level3.net (4.69.132.190) 7.999 ms 7.999 ms 7.999 ms 6 ae-2-54.edge3.Chicago3.Level3.net (4.68.101.116) 7.999 ms ae-2-52.edge3.Chicago3.Level3.net (4.68.101.52) 7.999 ms ae-2-54.edge3.Chicago3.Level3.net (4.68.101.116) 7.999 ms 7 4.68.63.198 (4.68.63.198) 7.999 ms 7.999 ms 8.000 ms 8 ae-1.r21.chcgil09.us.bb.gin.ntt.net (129.250.3.8) 8.000 ms 8.000 ms 8.000 ms 9 as-5.r20.snjsca04.us.bb.gin.ntt.net (129.250.3.77) 51.996 ms 51.996 ms 51.996 ms 10 xe-1-3.r02.mlpsca01.us.bb.gin.ntt.net (129.250.5.61) 55.995 ms 55.995 ms 55.995 ms 11 mg-1.c00.mlpsca01.us.da.verio.net (129.250.24.202) 55.995 ms 55.995 ms 59.995 ms 12 128.121.150.245 (128.121.150.245) 55.995 ms 51.995 ms 51.995 ms 13 128.121.150.245 (128.121.150.245) 51.996 ms !X * * On Aug 10, 2009, at 2:57 PM, Ryan Sarver wrote: Wanted to send out a status update and let everyone know where the situation stands as of today at noon. - Most developers are reporting being back in operation as of noon on Sunday - We have changed our defenses to make sure API developers are better supported. As such the system has more general strain on it and thus will produce some more 502/503 errors. If you see them, you should do a geometric back off instead of just sending a new request. - OAuth should be fully operational - If you continue to have unexpected errors, please produce a packet trace so we can help debug and define the issue. I will continue to give periodic updates throughout the day as we know more, but as most apps are back in action the updates will be more based on new news. Please continue to let us know of any unexpected issues you may have. Thanks again for your continued patience and support. Best, Ryan
[twitter-dev] Can someone suggest a VB.NET Twitter API Interface that works?
catcalls, I would like to know what open source software you have contributed and where they are located. I need to know to avoid using your work at all costs. Many open source software projects have dependencies, this DLL has a dependency on Log4Net, the solution is simple, download and include log4Net in you your project and use the newest version of the library.. Log4Net page (first link in google) - http://logging.apache.org/log4net/index.html On Aug 13, 2009, at 7:23 PM, catcalls wrote: Oh, the problem is the DLL. I mean, how many ways can you encode a space? I can use the DLL to search, follow, and update a single word to my twitter account - but as soon as I use a space it fails. Believe me, it's the DLL. Furthermore, the update to the DLL (which he claims works) does not compile on my machine. Finally, I am his client, because I am using his wares. If you are coding for yourself, you do not release it onto the net. You only do that to get people like me, as clients. I offer support on all my open source work. I frequently release code - but the difference is - I test my code before release. As for your other suggestions - they are BETA - I want something that actually works and is at least 1.0 On Aug 13, 11:27 pm, Mark Turner m...@amerine.net wrote: On Thu, Aug 13, 2009 at 2:48 PM, catcallsg.obrzut3...@ntlworld.com wrote: I've been using a free Twitter API Interface that was coded in C# and I imported the DLL and it was working fine until I discovered I cannot post spaces to twitter updates! I mean, WHAT!? I'm willing to bet that the problem is not the DLL. So, I have basically coded this application with full interaction with this DLL and wasted the past three days of my time because the original coder was too lazy to get it to work for his clients. Rude. If you got it for free don't complain, nobody works on open-source/free libraries for anyone but themselves. The take the time out of their day to package it up and put it out there so other people can try to save time or headache or use their sweet ass code. They don't have to help you in any way, shape or form unless the choose to do so. And I sincerely doubt he would call you his 'client'. So, can someone recommend a library that they used and was really pleased with - I don't mind paying a small fee for something that actually works you see. I have a complete app coded that just needs the API Interface to work. I tried rewriting some OAuth code but kept getting nonce errors so I gave up. I might go back to that again though if this request fails as a last resort. A whole four seconds of googling brought up a page full of libraries and examples in a large amount of languages including .net ones. http://oauth.net/code And here is something that look promising: Main:http://code.google.com/p/oauth-dot-net/ Source:http://code.google.com/p/oauth-dot-net/wiki/SourceNotice?tm=4 Docs:http://lab.madgex.com/oauth-net/gettingatarted01.aspx/ Demos:http://lab.madgex.com/oauth-net/ Would you please stop asking for oauth+vb.net help here, its clogging up the 7gb that google gives me. Head over tohttp://oauth.netfor help.
[twitter-dev] Re: Early developer preview: Retweeting API
+1 on this. I think the ReTweet concept is more complex than the model in the Retweet API described. While twitter has always been a keep it simple service, I think you will find many users wont use this new functionality if they can't use it the way they do currently (with additional comments).. I think somehow a hybrid of simple rebroadcasting and commenting on the rebroadcast would be powerful enhancement to the Twitter service. Being able to track retweets is very cool, but being able to track what people say about the content they are redistributing is where the power of social communication lies, it drives the conversation forward by engaging more users.. On Aug 13, 2009, at 7:13 PM, stk wrote: I see two UI suggestions: 1) People may find it confusing to see the original author's name in their list, as it's not expected. I think it's better to show the name of the retweeter, rather than the original tweeter (although a link to the original tweet, in the form of the author's name, would be fine and expected). 2) A larger issue with the UI will be the ability to have an option to do one of three things: a) use the original tweeter's text in it's entirety. b) not use the original tweeter's text and instead, use the retweeter's comment - or - c) a mix of (a) and (b) Hope this helps. On Aug 13, 2:31 pm, janole s...@mobileways.de wrote: Will it be possible to comment on the retweeted tweet? If not, people might just continue to use the current RT ... convention. Retweeting can be a way of acknowledging a tweet or disapproving a tweet etc. If you search for RT in search.twitter.com you'll see a lot of commented retweets. Ole -- @janole / mobileways.de / Gravity
[twitter-dev] Re: Post status to Twitter mobile version via querystring
A quick google search shows how to use the Embeded Safari browser to change the user-agent. If you change the user-agent to something a desktop would use, it should work for you. Realize though that this will then give the desktop presentation of the website, which may not be ideal.. http://stackoverflow.com/questions/1095045/spoofing-the-user-agent-of-an-embedded-safari-browser-on-the-iphone On Aug 19, 2009, at 12:57 PM, Michael Paladino wrote: A friend of mine is working on an iPhone app that will provide an option to post some text to Twitter via the “status” querystring. For example,http://twitter.com/?status=My%20status%20update. This works fine from a desktop or laptop, but when on an iPhone, Twitter recognizes that it’s a mobile device and redirects to m.twitter.com which does not handle the “status” querystring. Anyone know a way to force Twitter to go straight to the non-mobile version or have any other work around? Thanks in advance. Michael
[twitter-dev] Re: Statuses/destroy is returning 400 even though tweet is deleted sucessfully
I am seeing this issue as well. Users are reporting it very frequently
now...
At first I thought it was a bug in the client, but it happens every
time I try to delete a status right now, and it has become one of the
highest reported bugs in out app.
Twitter reports 400 with the JSON below, but the message is
successfully deleted.
{
request:\/statuses\/destroy\/3587663087.json,
error:We could not delete that status for some reason.
}
Looking at this thread it seems to be a problem for at least a week,
can we get some kind of official nod that the issue is at least on the
Twitter teams radar?
On Aug 26, 2009, at 2:41 PM, Tom Nichols wrote:
+1 - I am experiencing the same problem.
I'm running Twitter API requests as part of a unit test for my code
(HTTPBuilder- http://groovy.codehaus.org/modules/http-builder/). This
has always worked fine up until a couple weeks ago. Looks like there
is a bug report here:
http://code.google.com/p/twitter-api/issues/detail?id=949
It might have something to do with the time between when the tweet is
posted and deleted -- at least in my case, my unit test creates the
tweet and deletes it just a second or two later. It could have to do
with cluster propagation -- i.e. the original post hasn't been
propagated to the node which is handling the 'delete.' I'm just
speculating of course, but before this error cropped up, I was seeing
a different behavior where sometimes the delete request would return
successfully, but my tweet would remain visible. This is probably a
similar root cause, except the delete occurs while the post is still
propagating, and makes it to a cluster node after the delete
propagates or something. I tried putting a delay of ~10s between the
post and delete, and it did not seem to help...
On Aug 19, 9:18 am, srikanth reddy srikanth.yara...@gmail.com wrote:
yes i too encountered this (both status/destroy and direct_messages/
destroy
are giving 400 error but the status gets deleted successfully. The
response
text says something like somehow we could not delete this tweet.
On Wed, Aug 19, 2009 at 3:38 PM, deepikagupta
deepikaggu...@gmail.comwrote:
Hi,
I am facing an issue with statuses/destroy API call. It returns 400
(bad request) even though mentioned tweet id is delered sucessfully.
The method was working fine few days back but started gicing trouble
recently.
Anyone having same trouble? Is anything wrong with this API call?
[twitter-dev] Re: Problems Connecting to the API
+1 also can not connect to twitter api from any of our servers. On Oct 18, 2009, at 10:32 AM, Mark Ng wrote: +1 can't connect from slicehost.com (I believe in St. Louis). 2009/10/18 Michael Ivey michael.i...@gmail.com: Further info I've collected: Can't connect from: ATT DSL in South Alabama ATT iPhone network Northwest Florida, probably Comcast Other users in Atlanta Scoble reported various flakiness Servers at Slicehost in the St Louis datacenter Can connect from: Blackberry in Atlanta Seesmic CoTweet Facebook iPhones in CA (@jess updated via Echofon a little while ago) -- ivey On Sun, Oct 18, 2009 at 8:40 AM, Dewald Pretorius dpr...@gmail.com wrote: Does anyone else have problems connecting to the API at the moment (Sunday morning October 18)? Dewald
[twitter-dev] Re: API 140 character truncation change?
+1 agreed On Oct 23, 2009, at 7:20 PM, Dewald Pretorius wrote: Instead of all of us having to do fancy tap-dances, the proper solution is for Twitter to issue an error response when a sent tweet is rejected for whatever reason. Dewald On Oct 23, 7:58 pm, AJ Chen cano...@gmail.com wrote: then, comparing the front part (without url at the end) of the status is probably sufficient. -aj On Fri, Oct 23, 2009 at 3:07 PM, Dewald Pretorius dpr...@gmail.com wrote: You cannot compare the status sent with the status returned when the status contains an URL. The returned status contains Twitter's own bit.ly shortened URL instead of the URL your status sent had. Dewald On Oct 23, 6:24 pm, AJ Chen cano...@gmail.com wrote: I noticed this behavior a long time ago (may be a month) and reported the problem on this list, but it did not get any response from the api team. I thought it was a bug, but just realized yesterday that the api probably ignores 140+ chars status update intentionally. but' I'm not sure this is the policy or temporary tactic to reduce workload on api. it would be good that api team can clasify on this issue. to check if this happens or not, you can compare the status sent to api and the status returned from api in your application code. -aj On Fri, Oct 23, 2009 at 1:51 PM, Naveen knig...@gmail.com wrote: Here are two threads related to this issue. http://groups.google.com/group/twitter-development-talk/browse_thread . .. http://groups.google.com/group/twitter-development-talk/browse_thread . .. It is an inconvenient change, not because they changed it, but because they did not announce that the change was happening. On Oct 21, 5:37 am, Dave Sherohman d...@fishtwits.com wrote: On Tue, Oct 20, 2009 at 07:37:03AM -0700, James Tymann wrote: Has anyone else noticed a change in the way that the 140 character limit is enforced via the API? I noticed a change sometime between the 13th and the 16th that is now causing all my 140+ character posts to be rejected by the API. Also a side note is that the api is not returning errors, they return proper responses however they are the proper response for the current status of the account, not the new status that was just attempted to be posted. My users first reported issues arising from this on the 15th, although I didn't identify the cause until the 17th, at which point I asked about it in #Net::Twitter and Marc Mims brought the question here under the subject line Bug? Updates 140 characters return success with prior update payload. See the discussion under that thread for more on it, but the overall upshot is: - This is an intentional (if poorly-announced) change, not a bug. - Status updates are known to be getting silently rejected in this manner both due to exceeding 140 characters and due to violation of the expanded no duplicates policy. - Twitter has not stated whether there are any additional circumstances beyond those two cases in which updates will be silently rejected. - Twitter has not stated any plans regarding adding an indicator for when a 200 OK status update has, in fact, been rejected. I am attempting to compensate for this change by checking the returned status ID against the previous highest-seen ID to determine whether the status returned with the 200 OK response is a new one or the user's pre-existing status. This seems to work, but does not indicate the reason for the silent failure, so I can't report the cause to my users. Andy Freeman has mentioned that, in the case of rejection due to duplication, this is also unsatisfactory in that it does not allow him to identify the original status which was duplicated. -- Dave Sherohman -- AJ Chen, PhD Chair, Semantic Web SIG, sdforum.orghttp://web2express.org Palo Alto, CA -- AJ Chen, PhD Chair, Semantic Web SIG, sdforum.orghttp://web2express.org Palo Alto, CA
[twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names)
Thanks for the quick response. I guess I was confused. On Oct 28, 2009, at 8:53 PM, Marcel Molina wrote: The cursors are for lists of lists and lists of users followed by/following lists. The statuses timeline for a given list takes all the same options you'd expect to manage status timelines. On Wed, Oct 28, 2009 at 5:43 PM, Naveen knig...@gmail.com wrote: How does one keep a list up to date for a client without the concept of since_id, like we have for the timeline methods? I look at a lists as just a different timeline (granted one filtered to specific users), but that is how I would expect to view them in a client. From my understanding of cursors, on each request we have to start at -1 (to start paging) and page until we find an id that we already have locally. While this will work, it has a high probability of always over requesting data.. So if I have a list with two people in it, and they only tweet once a week, when I poll for updates of this list (say every 30min) the data is going to be the same most of the time(last 100 messages that these two people post). This seems like a waste of bandwidth for Twitter and us.. Some may argue that bandwidth is cheap, but it really is not on mobile devices. Some carriers charge per kb, but even on unlimited plans every byte transferred translates to additional battery drain.. Is there some concept of the cursor that I am not understanding that will allow us to also filter based on something like since_id? So we want to get messages newer than we already have and notify the user that the list has something new to display. Thanks to anyone who can clarify if I am misunderstanding something. --Naveen On Oct 28, 6:14 pm, Marcel Molina mar...@twitter.com wrote: Real soon now. We appreciate everyone's patience while we gradually ramp up traffic to lists to ensure we've got all our ducks in a row. On Wed, Oct 28, 2009 at 2:53 PM, Rich rhyl...@gmail.com wrote: +1 to this Any news on when the rest of us devs can get access to this to work on our apps? On Oct 28, 8:11 pm, Jesse Stay jesses...@gmail.com wrote: Maybe a little more appropriate to post this to a private list (no pun intended) for beta users? I admit I feel a little jealous every time I see one of these updates, unless there's some way to get into the beta. Thanks, Jesse On Wed, Oct 28, 2009 at 2:00 PM, Marcel Molina mar...@twitter.com wrote: Two additions and two changes to the List API will be deployed in the next few days: * List descriptions We're adding a description to every list. You'll be able to specify a description when you create or update a list and the description will be included in the payload. * Cursoring through lists of lists All resources that return a list of lists will include next and previous cursors and will accept a :cursor parameter. * Finding by list id rather than slug When you change the name of a list, the slug will be updated to reflect that change. That means using the slug in the url for resources to operate on lists requires the onerous task of validating that the slug for the list you are about to do something with hasn't been updated since the last time you stored its slug. What a nightmare :-) Every list also has an id. This value won't change. We'll be changing the API to replace all instances of a list slug in urls to be list ids instead. * Consistent names The terminology we've used thus far for people you follow with a list is members. The terminology for people who are following a list is subscribers. We're going to mirror the terminology used for users and change it to followers and following respectively. So: /:user/lists/:list_id/memberships becomes /:user/lists/:list_id/ followers /:user/lists/:list_id/subscribers becomes /:user/lists/:list_id/ following As we deploy these changes we'll send out a heads up on the dev list and @twitterapi. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Twitter connection giving a 502 Bad Gateway error
I have seen these in our users logs as well. I wasn't sure if it was
twitter or a mobile gateway they were using.
On Oct 29, 2009, at 11:41 AM, hima wrote:
Hi
I am trying to collect users data from twitter, like the number of
followers, number of tweets, the time the user' account is alive and
similar statistics. I have done this before in august and got
appropriate results with my code.I ran the code again a week ago and
it worked and gave me results. The same code however, stopped working
since a week now responding with a 502 bad gateway error. I am not
able to connect to the twitter page and get the xml body. This is my
function to return the xml page:
public static String webget(String host, String doc, String username,
String password)
{
String body = ;
byte[] auth = Base64.decode(username + : + password );
String header = Get + doc + HTTP/1.0\r\n;
header += Authorization: Basic + auth ;
header += Accept: application/xml, text/plain, text/xml,
text/*\r
\n;
header += \r\n;
try
{
Socket sock = new Socket(host, 80);
OutputStreamWriter os = new
OutputStreamWriter(sock.getOutputStream
());
os.write(header);
os.flush();
sock.getOutputStream().flush();
BufferedReader br = new BufferedReader(new
InputStreamReader(sock.getInputStream()));
String str = null;
while ( (str = br.readLine()) != null)
{
body += str + \n;
}
sock.close();
}
catch(IOException ioe)
{
return ;
}
return body;
}
This function is called like this:
webget(twitter.com, /users/show/+UserId+.xml, USERNAME,
PASSWORD)
I have not made any changes to the code since august. I am guessing
there have been changes in the twitter API which is giving me this
error.However, nothing like this is mentioned in the forums. Can you
let me know if there are changes in the twitter API that is causing
this?
Thanks
Hima
[twitter-dev] Re: Subscribed Lists
+1 Is there no way to view the lists that a user is subscribed to? As a client, it seems kind of silly that we can't allow the user to view a list that they already subscribe to with out them having to go find the list again. Kind of a big hole, because that means we will have to cache a separate list of lists that user uses frequently and it wont be the same as on Twitter website. On Oct 30, 2009, at 7:00 AM, David Neubauer wrote: Has any figured out how to get a the lists I'm subscribed to. I didn't realize how much I'd want this part of it. Please say it's coming... -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Jeremy Felt Sent: Thursday, October 29, 2009 8:16 PM To: Twitter Development Talk Subject: [twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names) It appears that user/lists.xml only shows lists that are created by the user and not those that they follow. Any change coming to that or am I missing a way to see all lists that a user follows? Thanks, Jeremy On Oct 28, 3:00 pm, Marcel Molina mar...@twitter.com wrote: Two additions and two changes to the List API will be deployed in the next few days: * List descriptions We're adding a description to every list. You'll be able to specify a description when you create or update a list and the description will be included in the payload. * Cursoring through lists of lists All resources that return a list of lists will include next and previous cursors and will accept a :cursor parameter. * Finding by list id rather than slug When you change the name of a list, the slug will be updated to reflect that change. That means using the slug in the url for resources to operate on lists requires the onerous task of validating that the slug for the list you are about to do something with hasn't been updated since the last time you stored its slug. What a nightmare :-) Every list also has an id. This value won't change. We'll be changing the API to replace all instances of a list slug in urls to be list ids instead. * Consistent names The terminology we've used thus far for people you follow with a list is members. The terminology for people who are following a list is subscribers. We're going to mirror the terminology used for users and change it to followers and following respectively. So: /:user/lists/:list_id/memberships becomes /:user/lists/:list_id/ followers /:user/lists/:list_id/subscribers becomes /:user/lists/:list_id/ following As we deploy these changes we'll send out a heads up on the dev list and @twitterapi. -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio
[twitter-dev] Re: will user payload include lists_count soon?
+1 I was wondering this as well. On Oct 30, 2009, at 2:23 PM, Jim Gilliam wrote: I assume lists_count must be coming to the user payload, but haven't heard anyone mention it. Jim
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.
[twitter-dev] Re: New methods for pending follow requests
Is there API endpoints planned to accept/reject incoming and cancel outgoing pending requests? I am curious, what the use case is for a list of ids for pending requests? Without APIs to interact with pending requests, what would this information be used for? For a mobile client, exposing this type of information is valuable to the user, but user objects (not ids) would be required to create a UI for someone to view and then interact with such requests. --Naveen Ayyagari @knight9 @SocialScope On Apr 13, 7:32 pm, Dana Contreras d...@twitter.com wrote: We've deployed two new methods for retrieving pending follow requests for protected users: * /friendships/incoming * /friendships/outgoing The incoming method returns a list of users who have pending requests to follow the authenticating user. The outgoing method returns a list of protected users for whom the authenticating user has pending follow requests. Both methods return 5000 user IDs per page. Cursors are provided in the unlikely event that you need to page through a list of more than 5000 pending follow requests. Full documentation is here:https://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-in...https://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-ou... Enjoy! -- Dana Contreras Twitter Platform Teamhttp://twitter.com/DanaDanger -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: New methods for pending follow requests
I can understand the security issue with providing an endpoint. However, I am not sure there is a lot of value in displaying the information in a client, when the user would then be forced to leave the application, open a browser, possibly login, then click pending requests, then find the user they want to approve from the list they had already been reading, then finally be able to take action to approve or deny. Maybe twitter could consider some providing a url that a client can launch that would take them directly to the approval for a user. Ideally this would work for m.twitter.com and twitter.com Already there is: http://m.twitter.com/friend_requests which asks the user to login and then takes them directly to friend_requests page. However it does not seem to be optimized on m.twitter.com for mobile clients, and is acutally quite unsightly and difficult to navigate on my BlackBerry (The Curve 8310 which is one of the most common BlackBerry models in the wild right now) Maybe friend_requests could be extended to allow something like: http://m.twitter.com/friend_requests/UID or http://m.twitter.com/friend_requests?id=uid This would allow a client to launch a browser and twitter to display a simple accept/reject page directly without much additional user interaction. When browsing on a mobile client, the fewer clicks it takes a user to take a specific action, the more likely they are to engage. Actually, a slightly more complex implementation (maybe overkill), but may provide better user experience: http://m.twitter.com/friend_requests?src_id=uidtarget_id=uid Where src_id is the uid of the user making the request (i.e. if I was using this from my account src_id would be my uid and target_id would be the uid of the user I want to approve or reject). By including the src_id, twitter can determine if there is a current twitter session in the browser and if the src_id is equal to the uid of current session, then a login page may not be required and can skip the login step. Otherwise, just let the user login, then take them directly to the requested approval page. This version simply covers the case where the user is logged in as one user on the website, but as a different user in a client.. As I said, it may be overkill, and may be acceptable to just display an error message if the request is invalid. I think I was clear, but if not feel free to tear apart my assumptions or if there is some security risk I am not considering with this type of implementation? --Naveen Ayyagari @knight9 @SocialScope On Apr 13, 9:06 pm, Raffi Krikorian ra...@twitter.com wrote: Is there API endpoints planned to accept/reject incoming and cancel outgoing pending requests? no - there is not. its following the theory that a malicious client could then accept friend requests to your protected account without your knowledge. I am curious, what the use case is for a list of ids for pending requests? Without APIs to interact with pending requests, what would this information be used for? to display to the end user. for the end user to take action, a twitter client could redirect them to a twitter.com site. For a mobile client, exposing this type of information is valuable to the user, but user objects (not ids) would be required to create a UI for someone to view and then interact with such requests. users/lookup would help with that. -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: dev.twitter.com
This is great. I love the twurl interface at http://dev.twitter.com/console Just a thought/suggestion, a link to the documentation when a method is chosen from the drop down list. Its not critical, i can look it up; it would just be a nice extra to save me a few extra clicks. --Naveen Ayyagari @knight9 @SocialScope -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: Slow response to twitter updates for a third party app
We see the same huge latency and timeouts as well (our timeouts are also at 30 seconds). We running out of a US data center on multiple machines, we see this issue on all if our servers. I agree with @tjaap, would like to hear twitters reaction as well. On May 7, 6:02 pm, Tjaap jdmeij...@gmail.com wrote: I'm seeing exactly the same: big latency and a lot of timeouts. When posting a tweet, Twitter sometimes does not return a response within 30 seconds. After my curl times out, the app has no way of knowing if the post made it or not. Sometimes it will appear on Twitter and sometimes it won't. This effectively breaks our app. Replicated the error on two different servers (in the Netherlands) and with different accounts. I would very much appreciate a reaction from Twitter on this. We are in the process of switching to OAuth, but I would like to know if I have to implement a workaround while we're on the old system. Thanks, @tjaap
[twitter-dev] Re: Slow response to twitter updates for a third party app
I dont have tcp dumps available.. Ill try to get some captures later this weekend.. Ill also run through the logs to see if they have any correlation with top of the hour, but my gut instinct is they do not. Anywhere specific I should send tcp dumps, as they may contain username and passwords of our users (we are still in the process of switching over to OAuth)? Should I just XXX those out? On May 8, 1:50 pm, Ryan Sarver rsar...@twitter.com wrote: Raj, Naveen, @tjaap, Do any of you still have tcp dumps of the calls you were making that were getting long timeouts? On Sat, May 8, 2010 at 12:08 AM, Naveen Ayyagari nav...@getsocialscope.comwrote: We see the same huge latency and timeouts as well (our timeouts are also at 30 seconds). We running out of a US data center on multiple machines, we see this issue on all if our servers. I agree with @tjaap, would like to hear twitters reaction as well. On May 7, 6:02 pm, Tjaap jdmeij...@gmail.com wrote: I'm seeing exactly the same: big latency and a lot of timeouts. When posting a tweet, Twitter sometimes does not return a response within 30 seconds. After my curl times out, the app has no way of knowing if the post made it or not. Sometimes it will appear on Twitter and sometimes it won't. This effectively breaks our app. Replicated the error on two different servers (in the Netherlands) and with different accounts. I would very much appreciate a reaction from Twitter on this. We are in the process of switching to OAuth, but I would like to know if I have to implement a workaround while we're on the old system. Thanks, @tjaap
[twitter-dev] Re: parsing out entities from tweets (a.k.a. parsing out hashtags is hard!)
+1 on the additional parameter to optionally request the data. Every byte counts for mobile device battery life and download time. --Naveen Ayyagari @knight9 On May 13, 8:13 pm, Dewald Pretorius dpr...@gmail.com wrote: Raffi, This is all good, but can you please make the inclusion in the tweet payload optional? Meaning, only include it if it is requested by an additional parameter? I, and I'm sure a lot of others, are already parsing the tweet text. This is just going to consume additional bandwidth and not add any value for us. It will add value for folks who are not already doing the parsing or don't know how. So, they can just request this additional payload.
[twitter-dev] Unexpected search results from search.twitter.com and API
Hello, I have seen this a few times in the last couple of days and did not see it mentioned on the list. If it is a duplicate report I apologize. A simple search is on a keyword, the first result does not contain the keyword at all, here is a screen shot displaying the behavior on search.twitter.com website. http://dl.dropbox.com/u/27113/search_wierdness.jpg I have seen this strange behavior via the api as well and it is a bit confusing. --Naveen Ayyagari SocialScope @knight9
[twitter-dev] @replies missing
Hello, Hoping we can get post on status.twitter.com about @replies not showing up... We have been getting a lot of reports that they are missing, and a quick twitter search seems to indicate it is not limited to our application. http://search.twitter.com/search?had_popular=trueq=repliesresult_type=recent
[twitter-dev] Re: @replies missing
John it seems to me that people still may be having some issues with @replies right now long after 2300UTC.. I have not specifically seen any reports for us, but its late and I assume they will start up again in the morning if there are still issues. http://search.twitter.com/search?q=replies Some samples from the past 10 minutes, missing replies, no replies, replies from 2009 only...: http://twitter.com/cenkbaban/statuses/1104103 http://twitter.com/mindcaster/statuses/1223601 http://twitter.com/phoenixemk/statuses/1163872 http://twitter.com/ak_hepcat/statuses/1163458 http://twitter.com/fredfiigglehorn/statuses/1065440 http://twitter.com/happyBeSacky/statuses/1057244 http://twitter.com/dcorsetto/statuses/17776966516 --Naveen On Jul 4, 9:42 pm, John Kalucki j...@twitter.com wrote: I don't have all the details, but there was at least one deploy today around this issue. Any reports of missing mentions from tweets sent after about say 23:00 UTC (4pm PDT) ? -John Kaluckihttp://twitter.com/jkalucki Infrastructure, Twitter Inc. On Sun, Jul 4, 2010 at 6:25 PM, Mike Champion mike.champ...@gmail.comwrote: I can see at least 1 missing tweet from my mentions list (at 9:20pm EDT 7/4/2010) This tweet:http://twitter.com/RodBegbie/status/17703020160 http://api.twitter.com/1/statuses/show.json?id=17703020160 doesn't appear in my mentions (permalink to my mentions via twitter hurl, but requires login. Is there a better permalink to send?): http://bit.ly/c79poT The tweet was sent ~20 hours ago, and doesn't appear in the mentions, even though newer mentions do. -mike On Jul 4, 4:25 pm, John Kalucki j...@twitter.com wrote: The mentions timelines were updating with additional latency, perhaps a few minutes, for about a day, but they were updating. They should be updating in near real time now. -John Kaluckihttp://twitter.com/jkalucki Infrastructure, Twitter Inc. On Sun, Jul 4, 2010 at 1:16 PM, Naveen Ayyagari nav...@getsocialscope.comwrote: Hello, Hoping we can get post on status.twitter.com about @replies not showing up... We have been getting a lot of reports that they are missing, and a quick twitter search seems to indicate it is not limited to our application. http://search.twitter.com/search?had_popular=trueq=repliesresult_ty. ..
Re: [twitter-dev] New Twitter bug?
Not that I am advocating any change because I prefer the way it works now. But this has been a point of confusion for some of our users as well. The issue stems from when a user uses xAuth to authenticate, they understand it as they have used their password so if they change the app should no longer have access. When a user uses the OAuth flow on the web, they generally seem to understand they are granting access to the application regardless of password. Some other services that use xAuth like authorization schemes will actually invalidate the OAuth connection when the user changes their password IF they have been authorized using the xAuth like mechanism. This is confusing for us as the developer, but seems to make sense to the majority of users. I think this is more of a user education issue than an actual technical issue.. --Naveen On Feb 2, 2011, at 6:53 AM, Scott Wilcox wrote: Hello, Tweetdeck uses the OAuth/Streaming API which is independent of your password. Are you suggesting that when you change your password it should invalidate your OAuth connections? If so, then no, it does not do that. Scott. On 2 Feb 2011, at 14:18, cazz wrote: I can hardly believe it's true but I discovered a rather strange issue Once you've added a twitter account to Tweetdeck, you're allowed to tweet from that account via Tweetdeck. No surprises so far But when you change your password in Twitter, there's no account/ password check again in Tweetdeck. Which means that once you've changed your password in Twitter, you don't exclude other twitterclients from having acces to your Twitteraccount!!! I would expect every time posting a tweet there should be a credentials check So this seems not very logical to me, or is it just me thinking this smells pretty much like a bug? See my tweet: http://twitter.com/#!/Cazz/status/32802305644433408 Cheers, Cazz -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] Unable to post status
Hi, I get the below error when i try to post a status update using twitter4j. I am not sure if i am missing any libraries in my build path: java.lang.NoSuchMethodError: com.google.appengine.api.urlfetch.FetchOptions.setDeadline(Ljava/lang/ Double;)Lcom/google/appengine/api/urlfetch/FetchOptions; Thanks, -Naveen -- Have you visited the Developer Discussions feature on https://dev.twitter.com/discussions yet? Twitter developer links: Documentation and resources: https://dev.twitter.com/docs API updates via Twitter: https://twitter.com/twitterapi Unsubscribe or change your group membership settings: http://groups.google.com/group/twitter-development-talk/subscribe
[twitter-dev] Search for India Tweets returns tweets from Indonesia
Hi, When my application (www.ookull.com) runs queries of type - http://search.twitter.com/search.json?q=*rpp=100geocode=17.38%2C78.48%2C925.0km to get tweets from India, I very often get tweets from Indonesia (Jakarta). Once in a while I also get tweets from Jamaica! I suspect that Jakarta and Jamaica are being confused for some Indian cities. Plz help. Thanks Naveen
