[twitter-dev] Re: Search API rate limit change?
Without prior notice, I can understand (circumstances), but without any kind of subsequent announcement?? Means we have to discover issues ourselves, verify that they're Twitter related (and not internal), then search around for existing discussion on the topic. Saves us a lot of time and headaches if Twitter would just announce stuff like this. On Mar 18, 2:51 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: We're working to reinstate the usual limits on the Search API; due to the impact of the Japanese earthquake and resultant query increase against the Search API, some rates were adjusted to cope better serve queries. Will give everyone an update with the various limits are adjusted. @episod http://twitter.com/episod - Taylor Singletary - Twitter Developer Advocate On Fri, Mar 18, 2011 at 11:39 AM, Hayes Davis ha...@appozite.com wrote: Hi, We're seeing this as well starting at approximately the same time as described. We've backed off on searching but are seeing no reduction in the sporadic limiting. It also appears that the amount of results returned on successful queries is severely limited. Some queries that often have 1500 tweets from the last 5 days are returning far fewer results from only the last day. Could we get an update on this? Hayes On Fri, Mar 18, 2011 at 10:13 AM, Eric e...@telvetto.com wrote: We're also seeing 400s on different boxes across different IP addresses with different queries (so it does not appear to be server or query specific). These began on all boxes at 2 a.m. UTC. We've backed off on both number and rate of queries with no effect. We've also noticed an increase in sporadic fail whales via browser based search (atom and html) from personal accounts, although we haven't attempted to quantify it. On Mar 18, 7:40 am, zaver zave...@hotmail.com wrote: Hello, After the latest performance issues with the search api i have been seeing a lot of 420 response codes.From yesterday until now i only get 420 responses on the every search i make. In particular, i search for about 100 keywords simultaneously every 6 mins. Why is this happening? Was there any change on the Search API limit? Any help is greatly appreciated. Thanks, Zaver -- 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 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] Related Results reliability issues
Hello Twitter API team. To get replies to specific tweets, I've been building on the related_results API method that was announced by Matt nearly a month ago. I'm seeing a mixed bag of results, including: * Rate limit excedeed for this one method, after just one or two calls * NOT getting replies at all when I do get results * Maximum six tweets in results. * Inconsistent results from the same call when called back-to-back As far as I can tell this method has been broken for at least a week. Would love to have some guidance as to when we can expect consistent results from this particular API call... I understand you need data from the real world to help tune these methods, but for those of us who are developing applications on top of these new methods, is there any way around the chaos? Getting rate limit exceeded, and seeing 'abData-experiment_key' in the results, makes me think there may be a way to get an account white-listed for the good results to this method! At very least, can you let us know when we can expect extended periods of consistent, correct behavior from related_tweets, so I can (re)set expectations w/ my clientele? Thanks, - Waldron Faulkner @WaldronFaulkner @GraphEdge -- 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: OAuth success but getting intermittent 500 Internal Server Error requesting access token
Our app had same issue, was mostly OK overnight, but we did see the odd failure. Is there an update on what happened? Thanks! - Waldron GraphEdge.com On Nov 11, 1:29 pm, Yu-Shan Fung ambivale...@gmail.com wrote: Hi All, I've been getting a high number of 500 errors (about 50% of the time yesterday) after user authenticated via oauth, and I try to get the access token from twitter. The weird thing is that the error is not consistent, and the exact same code/setup works about half the time, with the same test user acocunt. I'm using the ruby oauth gem and here's the error it returns 500 Internal Server Error /usr/lib/ruby/1.8/net/http.rb:2097:in `error!' [RAILS_ROOT]/vendor/gems/oauth-0.3.5/lib/oauth/consumer.rb:199:in `token_request' [RAILS_ROOT]/vendor/gems/oauth-0.3.5/lib/oauth/tokens/request_token.rb:18:in `get_access_token' Any idea what could be causing this? Thanks, much appreciated! Yu-Shan -- “When nothing seems to help, I go look at a stonecutter hammering away at his rock perhaps a hundred times without as much as a crack showing in it. Yet at the hundred and first blow it will split in two, and I know it was not that blow that did it, but all that had gone before.” — Jacob Riis
[twitter-dev] Re: API Proposal : Bulk fetch of user details
I'm completely on board with any strategy that will simplify (or especially amplify) the amount of graph data I can get. I had a discussion recently with Ryan where he indicated an openness to ideas of this sort because there is (he says) no getting around the 20K rate limits... an idea I find preposterous, but OK... whatever! So I'll be very interested to see if we can gain any traction on this front. I definitely can't get the amount of data I need to keep my app reasonably fresh with the rate limits available. - Waldron GraphEdge.com On Oct 22, 2:52 pm, Harshad RJ harshad...@gmail.com wrote: Hi, I am collating the thoughts in this thread [1] into a proposal to improve the efficiency of social-graphing applications. A common API access pattern for social-graphing applications seems to be: 1. Get the friend/follower ids of a user with [*friends/ids*] or [* followers/ids*] 2. Get user details one at a time with [*users/show*] (This approach saves on bandwidth by not using the [*statuses/friends*] method, as that would return redundant info when traversing a network) Now, since [*users/show*] is not a paginated API, it is easily possible to save bandwidth and connection overhead by clubbing multiple requests in one call. For a social-graphing application, the amount of user information needed is minimal. For example, the following amount of information would be sufficient for my application [1]: ?xml version=1.0 encoding=UTF-8? user id1401881/id screen_namedougw/screen_name followers_count1031/followers_count friends_count293/friends_count created_atSun Mar 18 06:42:26 + 2007/created_at statuses_count3390/statuses_count status created_atTue Apr 07 22:52:51 + 2009/created_at /status /user This is significantly smaller than the data returned by [*users/show*]. To prevent misuse of the new API the following could be enforced: 1. A maximum limit on number of users that can be queried in one request 2. Rate limiting based on number of users requested. For example, if (N) users' details were requested in one call, count it as (N/2) requests. This will provide incentive for using the new API as well as dettering misuse. [1]http://groups.google.com/group/twitter-development-talk/browse_thread... [2]http://twinkler.in cheers, -- Harshad RJhttp://hrj.wikidot.com
[twitter-dev] Re: Whitelisted IPs only work when authed?
Are you sure your requests are coming from the same IP you whitelisted? If you're on a shared host, for example, your outbound requests may come from a different IP as your dedicated inbound IP. I had this issue, had to bind curl to my dedicated IP, and it worked fine. Setting the CURLOPT_INTERFACE option is what worked for me. On Oct 9, 5:08 pm, Charles colei...@gmail.com wrote: I recently received email that confirmed my whitelisting status. I have several IPs whitelisted, as well as the account. From a shell on one of the whitelisted servers, I make a couple requests and then try: curlhttp://twitter.com/account/rate_limit_status.xml ?xml version=1.0 encoding=UTF-8? hash hourly-limit type=integer150/hourly-limit reset-time-in-seconds type=integer1255123230/reset-time-in- seconds reset-time type=datetime2009-10-09T21:20:30+00:00/reset-time remaining-hits type=integer147/remaining-hits /hash If, on the other hand, I try: curl -u username:passwordhttp://twitter.com/account/rate_limit_status.xml hash remaining-hits type=integer1/remaining-hits reset-time type=datetime2009-10-09T21:57:09+00:00/reset-time hourly-limit type=integer2/hourly-limit reset-time-in-seconds type=integer1255125429/reset-time-in- seconds /hash I was under the impression I did not have to auth if I was making calls from the API? Also: if I use my application's oauth credentials to generate an oauth_request and use the oauth URL, I am still getting the lower rate limit. Is this normal behavior?
[twitter-dev] Radio Silence on API Request?
Hey, Twitter API staff, can you recommend a next step for me to take? It's been more than a week since I issued a rate-limit request, and I haven't heard anything, nor seen any changes. What to do when the rate limit request form yields radio silence? Thanks! - Waldron Faulkner @WaldronFaulkner
[twitter-dev] Re: About the oneforty application directory
The rev-share doesn't kill the deal for me, although it does feel steep, and just because Apple gets 30% for the app store, not sure that number works in all cases. Also 60 day terms are discouraging. But the killer for me is the support-only clause. If I can't own the relationship, that makes it a total no-go. On Sep 27, 4:14 pm, Jim Renkel james.ren...@gmail.com wrote: I agree! Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Dossy Shiobara Sent: Sunday, September 27, 2009 14:08 To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: About the oneforty application directory Frankly, I don't even like the idea of read-access for an application like this. It would be nice if Twitter made authentication only as an option for OAuth. Better would be an option on the accept/deny OAuth page where users can select what access to grant to an application - defaulting to perhaps what access the application desires. On 9/25/09 8:04 PM, Jim Renkel wrote: What will you be using my twitter account for, other than authorization? If you reregister the site to only need read access to my twitter account, I would be a lot less reluctant to use it. -- 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)
[twitter-dev] Re: Are account suspensions permanent?
For the record, it's not because I have an account that's suspended, it's because I want to know whether my analytics platform I can permanently stop tracking suspended accounts, or whether I have to periodically check back in to see if they're still suspended. I wonder what the rate of reinstatement is, because if it's small, it'll save my app a lot of cycles to just permanently ignore these users. On Sep 23, 12:52 am, Adam Cloud cloudy...@gmail.com wrote: I had an experience that took over 4 months of back and forth, forth being me, back being them marking my ticket as taken care of without doing anything. I finally just created a new account, changed the name of the old one and used that name for the new one. Had another experience where the account was fixed after two unanswered tickets without a word said to the person. So you may have a few days, a week, a few months, maybe forever of being suspended without getting an actual account banning. Twitter may have excellent interaction with their 3rd-party developers, but their customer service blows.
[twitter-dev] Are account suspensions permanent?
I can save a lot of trouble if I know that a previously suspended Twitter user won't later have his/her suspension lifted. Anyone?? Waldron
[twitter-dev] Re: Comments for the group and Twitter staff
Thanks API team for implementing the cursoring, really needed it (could you tell!?). I have to go implement that right now. On Sep 16, 9:24 am, citricsquid s...@samryan.co.uk wrote: This. I've always thought that the obvious path would be to have unique error codes that never change. So if there's an auth fail it returns 1234 and 1234 corresponds to a specific message that is called externally. So we send the error code we're getting and it replies with the message and a description. So say they decide to change auth fail to auth has failed developers see no changes, unless they're using the twitter error message and then the message changes. So we have unique error codes that, when requested, return an error message that can be changed whenever you guys like and has no affect on developers and their apps. So for debugging we can simply call the description and error message from the code, but in a live environment we can build our own error handling based upon the error code, without having to constantly watch out for changes. Apologies if that lacks sense, not very good at explaining. On Sep 15, 9:21 pm, PJB pjbmancun...@gmail.com wrote: Please also stop willy-nilly changing the error codes and error messages. Since your error messages are so often inaccurate, some of us have setup special rules to decipher what the errors actually are -- when you change the text or code, our rules break. For example, suspended users are/were getting rate limit warnings when trying to authenticate as them. Separately, a new not authorized message appears for both failed authentication errors as well as successfully authenticated users trying friends/ids on blocking users. Since the messages and codes are the same, it is hard to distinguish between these error types to tell the user what is going on. There are about a half-dozen of these ambiguities and bad errors that we've accounted for. (Don't get me started on 200: OK non- errors.) So, after much trial and error, we CAN figure out the actual underlying problem based on the action and message you send us. But when you suddenly change the error code, or message, it throws our rules into disarray. (Of course, it would be nice if the actual error messages you sent were themselves accurate, but for now we're just hoping you can CONSISTENTLY send us the same inaccurate errors.) On Sep 15, 12:29 pm, Alex Payne a...@twitter.com wrote: We're planning on doing just that: communicating more, monitoring the API via a third-party service from a variety of locales, and providing better documentation. We've got more developer support hires lined up, and more. Thanks for the list of what you'd like to see, and thanks for bearing with us. On Tue, Sep 15, 2009 at 12:13, zippy_monster alex.zep...@gmail.com wrote: On Sep 15, 11:04 am, Alex Payne a...@twitter.com wrote: Please understand that the denormalized lists are currently provided to developers on a best-effort basis. For the vast majority of Twitter applications, this data isn't necessary. A specialized class of applications need this data, and we're doing our best to provide it. As a developer, implementation details are mainly a recreational interest. My primary concern is the end result (does it work? or not?). Excuses and apologies are nice, but not a substitute for more explicit testing and communication. So far I've run into two disruptive changes: - Today, for a brief period, API queries were returning twice the number of responses they should have. Instead of showing the proper 6 DMs, I was getting 12 back. Oops. - Previously, the way POST + OAuth requests were being handled changed. The code I was using (MGTwitterEngine + various OAuth hacks) was sending GET arguments with every request (even POST). For a while this worked, but in the past few weeks this broke with no warning. Yeah, that was sloppy client-side code, but the documentation was silent on this, and certainly the error message (invalid/re-used nonce) was not terribly helpful as a proper nonce was being generated each time. Additionally, Internet rumblings about how OAuth was handled lend credence to the idea that the API just isn't terribly stable... both from the idea that you're pushing people to use what is officially considered an experimental API, and that it's being treated as an experimental API (OAuth specific outages for instance). Or, the current pagination problems. The threads I see here seem to all be started by API consumers. What's missing from the picture is an announcement from Twitter that some feature is broken. That smacks of really poor (well, non-existent) communication. So, yeah, after spending time tracking down the above problems, and reading general internet rumblings, my gut feeling is
[twitter-dev] Re: Comments for the group and Twitter staff
Ryan, please look no further than existing, accepted issues in the issues list for examples as to how this platform is not yet ready. One of your primary API calls, followers/ids (and friends/ids) is broken, and has been for more than a week now. Since paging is not working, and un-paged requests on accounts with many followers yields fail whale, we CANNOT GET LISTS OF FOLLOWERS. That is a major failure, and it doesn't feel like it's getting any kind of response. As I have said repeatedly in this forum and in the issues list, this has frozen business development for my fledgling business, which I have trusted to the Twitter API. I can't show a broken product. At some point, you will put this little dream of mine out of business. I'm up late working on my project, which will ultimately add value to Twitter's business. I hope your team isn't leaving me high and dry. Please tell me I don't have to go do a Facebook app instead. Please tell me that someone was working on this over the weekend. I'd love to have some solid, no-nonsense response to this, with hard dates. So far we've had well-meaning but empty words. Thanks, - Waldron Faulkner Founder, GraphEdge LLC. http://graphedge.com On Sep 15, 2:59 am, Ryan Sarver rsar...@twitter.com wrote: WyoKnott, Thanks for your email. We really appreciate the candid feedback and definitely is not something we want to see happening. I would like to hear more about what you mean by not stable enough and what specific issues we can work on that would get you to consider Twitter a platform worthy of building your business on. I look forward to your feedback. Best, Ryan On Fri, Sep 11, 2009 at 6:36 AM, WyoKnott mycro...@lifewithindustry.com wrote: A few months ago I was introduced to the Twitter API by a prospective client who wanted a custom application. I took the time to learn the API and wrote a quick and dirty standalone windows app. The project fell through (the client could not get financing) but I have continued to be a twitter user and have subscribed to this group email. I stopped development on the project because the API does not yet seem stable enough for me to try to produce a marketable product on my own while at the same time chasing an API around. Is my opinion way off the mark or are some of the other developers out there feeling the same way. I am considering restarting development on the project if the Twitter API is likely to get more stable in the near future. Thanks for tolerating my ravings WyoKnott
[twitter-dev] Re: empty data + no error returned from friends/ids
Hello, Raffi, This is not the non-json response issue. This is open, accepted, high priority issue #1019. Be the hero that fixes this for us, it's breaking my back. Ryan and Alex aren't helping me out, maybe you can be THE MAN! Please fix this, PLEASE! On Sep 14, 6:36 pm, Raffi Krikorian ra...@twitter.com wrote: We are seeing random, intermittent empty result sets from friends/ids, called without page or cursor arguments. These empty results return without error, and frequently correct themselves when tried again. Is this a known issue? What is the status of this issue? hi PJB. i don't know of this particular issue, unless it is the same issue as the non json responses that have been reported: http://groups.google.com/group/twitter-development-talk/browse_thread... if so, we're actively working on it. if you think you have a different issue, if possible, could you send me a tcpdump of when that error occurs? thanks! -- Raffi Krikorian Twitter Platform Team ra...@twitter.com | @raffi
[twitter-dev] Re: Comments for the group and Twitter staff
OK Alex, thanks for that insight. I'm trying hard to be patient, but I hope you can understand that this issue is strangling my new business. Also, I don't see anything in the documentation which differentiates these social graph calls from those rising above support on a best- effort basis. I'm not trying to be argumentative, but it would help me tremendously with prioritization of ongoing development if I knew which other API calls won't receive priority support if they should suddenly fail. If there is some internal prioritization, I think the community needs to know what it is. I know I do! Thanks, - Waldron On Sep 15, 2:04 pm, Alex Payne a...@twitter.com wrote: Waldron, We're looking into this issue, but it requires a great deal of coordination with the folks who work on our back-end infrastructure. When you ask for a list of denormalized IDs, that request spends very little time in API code, and most of its time talking to a back-end system that my team has no control over. We're working with the folks in charge of that on reliability and better ways for developers to access that data. Please understand that the denormalized lists are currently provided to developers on a best-effort basis. For the vast majority of Twitter applications, this data isn't necessary. A specialized class of applications need this data, and we're doing our best to provide it. On Tue, Sep 15, 2009 at 00:21, Waldron Faulkner waldronfaulk...@gmail.com wrote: Ryan, please look no further than existing, accepted issues in the issues list for examples as to how this platform is not yet ready. One of your primary API calls, followers/ids (and friends/ids) is broken, and has been for more than a week now. Since paging is not working, and un-paged requests on accounts with many followers yields fail whale, we CANNOT GET LISTS OF FOLLOWERS. That is a major failure, and it doesn't feel like it's getting any kind of response. As I have said repeatedly in this forum and in the issues list, this has frozen business development for my fledgling business, which I have trusted to the Twitter API. I can't show a broken product. At some point, you will put this little dream of mine out of business. I'm up late working on my project, which will ultimately add value to Twitter's business. I hope your team isn't leaving me high and dry. Please tell me I don't have to go do a Facebook app instead. Please tell me that someone was working on this over the weekend. I'd love to have some solid, no-nonsense response to this, with hard dates. So far we've had well-meaning but empty words. Thanks, - Waldron Faulkner Founder, GraphEdge LLC. http://graphedge.com On Sep 15, 2:59 am, Ryan Sarver rsar...@twitter.com wrote: WyoKnott, Thanks for your email. We really appreciate the candid feedback and definitely is not something we want to see happening. I would like to hear more about what you mean by not stable enough and what specific issues we can work on that would get you to consider Twitter a platform worthy of building your business on. I look forward to your feedback. Best, Ryan On Fri, Sep 11, 2009 at 6:36 AM, WyoKnott mycro...@lifewithindustry.com wrote: A few months ago I was introduced to the Twitter API by a prospective client who wanted a custom application. I took the time to learn the API and wrote a quick and dirty standalone windows app. The project fell through (the client could not get financing) but I have continued to be a twitter user and have subscribed to this group email. I stopped development on the project because the API does not yet seem stable enough for me to try to produce a marketable product on my own while at the same time chasing an API around. Is my opinion way off the mark or are some of the other developers out there feeling the same way. I am considering restarting development on the project if the Twitter API is likely to get more stable in the near future. Thanks for tolerating my ravings WyoKnott -- Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x
[twitter-dev] Re: Paging STILL broken
That's awesome, Ryan, thanks. Can I get an ETA on a fix please? This is extremely important to my business, I need to know when I can begin selling. This bug has caused a delay, because I can't sell a broken product, even if it is Twitter's bug and not my own. So... ETA?? Thanks! On Sep 13, 5:49 pm, Ryan Sarver rsar...@twitter.com wrote: Waldron, Thanks for the email. I am working with our team internally to track down the issue and figure out how to resolve it. I will get back to you with an update shortly, but know that we are listening and working on this. Best, Ryan On Sun, Sep 13, 2009 at 8:55 AM, Waldron Faulkner waldronfaulk...@gmail.com wrote: PLEASE, can someone on the API team let us know when the paging bug(s) with followers/ids (and friends/ids) will be addressed? There have been problems with it for weeks, but now it's just downright broken. We can't get lists of followers for users with large numbers of followers. That's a basic, fundamental API feature that's just BROKEN. There's a reproduced, accepted, high priority bug against this issue in the issues area, starred by many, and we've had neither a fix, nor a comment as to whether it's even being addressed. I need to know that I can expect problems with the platform's basic functionality to be resolved within a reasonable time-frame. This is killing my business development efforts. If Twitter wants people to build businesses on this platform, they HAVE to support it. PLEASE guys, give us something. Don't make me throw away months of work and go focus on something unrelated to Twitter.
[twitter-dev] Paging STILL broken
PLEASE, can someone on the API team let us know when the paging bug(s) with followers/ids (and friends/ids) will be addressed? There have been problems with it for weeks, but now it's just downright broken. We can't get lists of followers for users with large numbers of followers. That's a basic, fundamental API feature that's just BROKEN. There's a reproduced, accepted, high priority bug against this issue in the issues area, starred by many, and we've had neither a fix, nor a comment as to whether it's even being addressed. I need to know that I can expect problems with the platform's basic functionality to be resolved within a reasonable time-frame. This is killing my business development efforts. If Twitter wants people to build businesses on this platform, they HAVE to support it. PLEASE guys, give us something. Don't make me throw away months of work and go focus on something unrelated to Twitter.
[twitter-dev] Re: Paging (or cursoring) will always return unreliable (or jittery) results
Hey developers, any hints/tips on how I can get the Twitter API team to focus on this issue? It's hard to build a business on the Twitter API when a crucial feature like this just stops working and we get radio silence for days. Any tips on how I can help the team focus on this?? On Sep 9, 10:10 am, alexc chy101...@gmail.com wrote: this issue still pops up :http://twitter.com/friends/ids/downingstreet.xml?page=3
[twitter-dev] Re: Paging (or cursoring) will always return unreliable (or jittery) results
I could really go for jittery right now... instead I'm getting totally broken! I'm getting two pages of results, using ?page=x, then empty. To me, it looks like all my accounts have max 10K followers. I'd love some kind of official response from Twitter on the status of paging (John?). Example: user @starbucks has nearly 300K followers, however: http://twitter.com/followers/ids.xml?id=30973page=3 returns empty result. - Waldron On Sep 7, 10:24 pm, John Kalucki jkalu...@gmail.com wrote: This describes what I'd call row-based pagination. Cursor-based pagination does not suffer from the same jitter issues. A cursor-based approach returns a unique, within the total set, ordered opaque value that is indexed for constant time access. Removals in pages before or after do not affect the stability of next page retrieval. For a user with a large following, you'll never have a point-in-time snapshot of their followings with any approach, but you can retrieve a complete unique set of users that were followers throughout the duration of the query. Additions made while the query is running may or may not be returned, as chance allows. A row-based approach with OFFSET and LIMIT is doomed for reasons beyond correctness. The latency and CPU consumption, in MySQL at least, tends to O(N^2). The first few blocks aren't bad. The last few blocks for a 10M, or even 1M set are miserable. The jitter demonstrated by the current API is due to a minor and correctable design flaw in the allocation of the opaque cursor values. A fix is scheduled. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Sep 6, 7:27 pm, Dewald Pretorius dpr...@gmail.com wrote: There is no way that paging through a large and volatile data set can ever return results that are 100% accurate. Let's say one wants to page through @aplusk's followers list. That's going to take between 3 and 5 minutes just to collect the follower ids with page (or the new cursors). It is likely that some of the follower ids that you have gone past and have already colledted, have unfollowed @aplusk while you are still collecting the rest. I assume that the Twitter system does paging by doing a standard SQL LIMIT clause. If you do LIMIT 100, 20 and some of the ids that you have already paged past have been deleted, the result set is going to shift to the left and you are going to miss the ones that were above 100 but have subsequently moved left to below 100. There really are only two solutions to this problem: a) we need to have the capability to reliably retrieve the entire result set in one API call, or b) everyone has to accept that the result set cannot be guaranteed to be 100% accurate. Dewald
[twitter-dev] Re: Followers count
Same oddness w. friends count as well? I'd guess so. My problem is that if I try to get followers using paging, I get different numbers (and different followers) than if I pull the entire list w/o paging. Also, followers disappear and reappear from one hour to the next. On Sep 2, 5:44 pm, Jason Tan jasonw...@gmail.com wrote: Hello, I have spent a good portion of today reading through closed, merged, and open issues onhttp://code.google.com/p/twitter-api/issues/list I am trying to figure out the best way to get an accurate followers count. Initially, I was using /users/show which returns the full user object, including the followers_count item. However, I have noticed that this number only updates when the user posts a tweet. If the user has no new tweets, the follower count is not updated. Data I was pulling in was many days old. I understand the need to cache data, but being unable to pull up an approximate count of followers from the past several days is a problem. I have seen this issue posted many times, but it is always merged into issue 474, which appears to only deal with the following flag, and not the followers_count. There was one issue (which I can't find anymore) where there was acknowledgment that the users/show data was cached until a new post was made but no mention of any fix or solution. My next approach was to use the statuses/user_timeline. I wasn't sure if the user object for each status would have the current value or the value at the time of the status update. When I grabbed the xml formatted response, I got (starting from the most recent status and going back): 1686, 1653, 1685, 1685, 1685, 1685, 1685... Through the rest of the statuses, it stayed the same. Interestingly, 1686 is the current value listed on the website. 1653 was the value I got from /users/show. And I'm quite certain that the followers count did not stay constant at 1685. Moreover, when I grabbed the json version of statuses/user_timeline, I got entirely different results: 1653, 1653, 1683, 1675, 1652, 1661, 1644... This seems to reflect the current number of followers at the time of the status update, unlike the XML feed. Anyways, to get back to my original question. How do I get an accurate followers count for a user? Also, why are there still XML/ JSON discrepancies (I came across a few reported issues that said they had been resolved). Any help or suggestions would be very much appreciated! Thanks, Jason P.S. The account I was using for the above examples was DailyPHP
[twitter-dev] Rate Limit Weirdness?
Strange events w/ Rate Limit requests. I'm calling the API from my whitelisted IP and getting results that are all over the map. It's almost as if Twitter is load-balancing my requests to two different environments, each of which is keeping its own count of my rate limits. So my app chugs along happily thinking it has plenty of limits and shouldn't need to check for a while, and then wham, I'm getting 404's and Rate Limit exceptions. Check this output from one of my apps: Rate lims for acct: 7727 Rate lims for acct: 2002 2009-09-03 02:12:04 AM: Processed 1000 tasks (∞ / min) Rate lims for acct: 1136 2009-09-03 02:12:25 AM: Processed 2000 tasks (∞ / min) Rate lims for acct: 7052 2009-09-03 02:12:46 AM: Processed 3000 tasks (3000 / min) Notice how the rate lim requests bounce from the 7K to the 1K range Then, a few seconds later, I get a ton of 404, and finally an over-the- rate-lims response. This only happens from my whitelisted IP. I'm running the same app from home (account whitelisted but not the ip) and it runs without this problem. What's up??
[twitter-dev] Re: Rate Limit Change?
The explanation I've had makes sense. If you call from a whitelisted IP, it charges to the IP limit, regardless of authentication. IE, it, checks that first. On Aug 12, 5:30 pm, Zaudio si...@z-audio.co.uk wrote: I get the same with my apps; an authenticated and unauthenticated call to get rate limits returns the same hits available out of the 20K... never managed to get an answer why I'm guessing the authentication is being ignored, and I just get IP limits all the time? Just go towww.bullsonwallstreet.com?rate_limits=1 and look just above the footer... after the call completes, you see the two rate limits display and refresh every 10 sec or so... weird Simon On Aug 12, 1:51 pm, shiplu shiplu@gmail.com wrote: If its called from a whitelisted IP, It will be charged to IP. Not account. -- A K M Mokaddimhttp://talk.cmyweb.nethttp://twitter.com/shiplu Stop Top Posting !! বাংলিশ লেখার চাইতে বাংলা লেখা অনেক ভাল Sent from Dhaka, Bangladesh
[twitter-dev] Rate Limit Change?
Getting same response to my rate limit requests (http://twitter.com/ account/rate_limit_status.format), for both Account and IP. I think I missed something. I used to have two different, independent numbers for my account and IP rate limits (including different reset times). That is, I would have 20K account calls, plus 20K IP calls, each hour. This changed recently (within past 2 weeks?). Now, both numbers are reduced by 1 hit, whether I hit an account or api limited. My request returns same result, whether I'm logged in or not... although the XML isn't in the same order, so it's definitely still two different apps. Did I miss something? Is this a policy change, because the wiki doesn't reflect it. Thanks, - Waldron
