Re: [twitter-dev] Re: Search API rate limit change?
I just wanted to add to this. The 420s have let up for the most part and I'm no longer seeing rate limiting behavior significantly different from the norm. I've noticed that many result pages are coming back with empty results but if I re-request the same page (after a couple second delay), I can often get results for that page. These are for queries with very low tweet velocity, so it's not like these are new results coming in. Is this related to http://status.twitter.com/post/3785043723/slow-searches ? Thanks. Hayes On Mon, Mar 21, 2011 at 6:13 PM, Matt Harris thematthar...@twitter.comwrote: In many cases we are forced to change the rate limits in response to a significant increase in requests, which means it isn't always possible to give advanced notice of rate limit changes. For some of you it sounds like your code that handles rate limiting didn't react appropriately. When receiving a 420 response we recommend you stop making requests and then after the retry-after, slowly build up the number of requests you make. Put another way it isn't a good idea to make requests to the API at the velocity that caused the 420 response before. As always, the rate limits are there to ensure the system is responsive and available to as many users as possible. This means it is necessary to reduce the number of queries you can make without notice. The best place to stay informed about issues like this are posted through @twitterapi and published on the Twitter status blog: http://status.twitter.com/post/3785043723/slow-searches Best, @themattharris Developer Advocate, Twitter http://twitter.com/themattharris On Mon, Mar 21, 2011 at 7:41 AM, Colin Surprenant colin.surpren...@gmail.com wrote: By adjusting the rate limits to reduce the stress on your search api without notice you have significantly increased the stress level on our end :P Seriously, advanced notice of the situation would have been welcome. In particular what created lots of confusion on our end is that even after pausing for the specified retry_after delay we would immediately get repeated 420s at which point we started to assume our IPs were banned (which also contributed to increase the stress level). Colin On Mar 21, 9:12 am, Jeffrey Greenberg jeffreygreenb...@gmail.com wrote: Taylor, Yeah this was definitely NOT good.In the past, when there is a service disruption, your api group would post something on your status page and tweet about it... Instead, I'm finding out about this from my customers... Did y'all tweet about this or present this somewhere where I could find it? Jeffrey Tweettronics.com On Sun, Mar 20, 2011 at 3:14 PM, Waldron Faulkner waldronfaulk...@gmail.com wrote: 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
Re: [twitter-dev] Re: Search API Optional lang Has Problem.
I'm seeing this as well. Including filter:links or setting that language causes the search to fail. I get an error message saying since_id has been adjusted due to a temporary error. I'm *not* including a since_id in the search parameters. Hayes On Mon, Nov 29, 2010 at 10:08 AM, Randomness randomness.bl...@gmail.comwrote: Same problem here. When lang=all is used I am getting results. When a language is specified I get zero results most of the time, while in some cases I do get a result. Seems very strange. On Nov 29, 9:25 am, fbparis fbou...@gmail.com wrote: And same with some search operators (like source:xxx) Sorry for posting twice :) On Nov 29, 1:50 am, Jeong Hoon Kim redi...@gmail.com wrote: About 5 days ago, Suddenly Search API Optional lang had no results..My optional lang is ko. Did anybody apply Search API lang option? Did the results come out correctly?- Hide quoted text - - Show quoted text - -- 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
Re: [twitter-dev] Re: Snowflake: An update and some very important information
I did some investigation into the snowflake algorithm recently and yes, it's
safe for 64bit signed longs. Even if Twitter moved away from using
scala/java longs internally (which are definitely signed), you'd still have
something like 65 years from now before the algorithm rolled past the 2^63-1
barrier.
I've posted a a gist[1] in ruby with a few little methods for playing with
the time part of a snowflake id if you're interested.
Hayes
1 http://gist.github.com/634586
On Tue, Oct 19, 2010 at 6:27 AM, Dan Checkoway dchecko...@gmail.com wrote:
I'm also patiently awaiting a response from twitter about this. Are the
ids sane for 64-bit *signed* long?
Dan
On Mon, Oct 18, 2010 at 9:08 PM, jon jonhoff...@gmail.com wrote:
Hi,
You wrote that the IDs are unsigned 64 bit ints, but the IdWorker is
pumping out java Longs which are signed. I'm assuming that was a
typo, but please clarify.
http://github.com/twitter/snowflake/blob/master/src/main/scala/com/twitter/service/snowflake/IdWorker.scala
Thanks,
- Jon
On Oct 18, 8:19 pm, Matt Harris thematthar...@twitter.com wrote:
Last week you may remember Twitter planned to enable the new Status ID
generator - 'Snowflake' but didn't. The purpose of this email is to
explain
the reason why this didn't happen, what we are doing about it, and what
the
new release plan is.
So what is Snowflake?
--
Snowflake is a service we will be using to generate unique Tweet IDs.
These
Tweet IDs are unique 64bit unsigned integers, which, instead of being
sequential like the current IDs, are based on time. The full ID is
composed
of a timestamp, a worker number, and a sequence number.
The problem
-
Before launch it came to our attention that some programming languages
such
as Javascript cannot support numbers with 53bits. This can be easily
examined by running a command similar to: (90071992547409921).toString()
in
your browsers console or by running the following JSON snippet through
your
JSON parser.
{id: 10765432100123456789, id_str: 10765432100123456789}
In affected JSON parsers the ID will not be converted successfully and
will
lose accuracy. In some parsers there may even be an exception.
The solution
To allow javascript and JSON parsers to read the IDs we need to include
a
string version of any ID when responding in the JSON format. What this
means
is Status, User, Direct Message and Saved Search IDs in the Twitter API
will
now be returned as an integer and a string in JSON responses. This will
apply to the main Twitter API, the Streaming API and the Search API.
For example, a status object will now contain an id and an id_str. The
following JSON representation of a status object shows the two versions
of
the ID fields for each data point.
[
{
coordinates: null,
truncated: false,
created_at: Thu Oct 14 22:20:15 + 2010,
favorited: false,
entities: {
urls: [
],
hashtags: [
],
user_mentions: [
{
name: Matt Harris,
id: 777925,
id_str: 777925,
indices: [
0,
14
],
screen_name: themattharris
}
]
},
text: @themattharris hey how are things?,
annotations: null,
contributors: [
{
id: 819797,
id_str: 819797,
screen_name: episod
}
],
id: 12738165059,
id_str: 12738165059,
retweet_count: 0,
geo: null,
retweeted: false,
in_reply_to_user_id: 777925,
in_reply_to_user_id_str: 777925,
in_reply_to_screen_name: themattharris,
user: {
id: 6253282
id_str: 6253282
},
source: web,
place: null,
in_reply_to_status_id: 12738040524
in_reply_to_status_id_str: 12738040524
}
]
What should you do - RIGHT NOW
--
The first thing you should do is attempt to decode the JSON snippet
above
using your production code parser. Observe the output to confirm the ID
has
not lost accuracy.
What you do next depends on what happens:
* If your code converts the ID successfully without losing accuracy you
are
OK but should consider converting to the _str versions of IDs as soon as
possible.
* If your code has lost accuracy, convert your code to using the _str
version immediately. If you do not do this your code will be unable to
interact with the Twitter API reliably.
* In some language parsers, the JSON may throw an exception when reading
the
ID value. If this happens in your parser you will need to ‘pre-parse’
the
data, removing or replacing ID parameters with their _str versions.
Summary
-
1) If you develop in Javascript, know that you will have to update your
code
to
[twitter-dev] new_id Gone From Streaming API Statuses
Hi, I was attempting to test my apps with the new status_ids but it appears that the new_id field is no longer being included in the Streaming API json. They were there earlier in the week but are no longer being included. According to John Kalucki's post on the subject[1], I was under the impression this would be enabled from 9/30 until the transition. Are there plans to re-enable this before the transition on Tuesday? Hayes [1] http://groups.google.com/group/twitter-development-talk/browse_thread/thread/9cf92935379d8022/e4eaa56485b2e2e7 -- 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
Re: [twitter-dev] Unable to connect to the Streaming API over SSL
Thanks, Tayor. Will do. It'd be nice to have that explicitly stated in the docs. Hayes On Wed, Oct 6, 2010 at 4:17 PM, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Hayes, The public streaming API endpoint at stream.twitter.com had SSL support turned off recently -- we hadn't, I believe, ever explicitly documented that it supported SSL. I wasn't aware of this change and have some issues with it -- I'll see what I can do. In the meantime, please use non-SSL. Taylor On Wed, Oct 6, 2010 at 3:35 PM, Hayes Davis ha...@appozite.com wrote: Hi all, For several months now, we've been connecting to the streaming api filter resource over SSL without issue. Today it suddenly disconnected us and wouldn't let us reconnect. We tried from multiple IPs to connect without success so it doesn't appear to be some sort of blacklist issue. Is this a temporary outage or something more permanent? If it's temporary, is there any ETA on a resolution? Please let me know if there's more information I can provide to help resolve this. Hayes -- 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] Unable to connect to the Streaming API over SSL
Hi all, For several months now, we've been connecting to the streaming api filter resource over SSL without issue. Today it suddenly disconnected us and wouldn't let us reconnect. We tried from multiple IPs to connect without success so it doesn't appear to be some sort of blacklist issue. Is this a temporary outage or something more permanent? If it's temporary, is there any ETA on a resolution? Please let me know if there's more information I can provide to help resolve this. Hayes -- 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
Re: [twitter-dev] Re: Open Source Streaming libraries that use oAuth?
I believe the twitter-stream[1] ruby library supports OAuuth as of the latest version. I haven't personally used the OAuth yet but it's been rock solid for me with basic auth. Hayes [1] http://github.com/voloko/twitter-stream On Wed, Aug 4, 2010 at 7:39 PM, Mark McBride mmcbr...@twitter.com wrote: For ruby, check out twurl twurl -t -U -Hstream.twitter.com /1/statuses/sample.json Should be pretty easy to reverse engineer what the command line tool is doing and go from there. ---Mark http://twitter.com/mccv On Wed, Aug 4, 2010 at 4:55 PM, M. Edward (Ed) Borasky zn...@borasky-research.net wrote: Perl or Ruby are preferred, but any language will work if it doesn't have an outrageously heavyweight runtime. -- M. Edward (Ed) Borasky http://borasky-research.net http://twitter.com/znmeb A mathematician is a device for turning coffee into theorems. - Paul Erdos Quoting Tom allerleiga...@gmail.com: In which language? Tom On Aug 5, 1:01 am, M. Edward (Ed) Borasky zn...@borasky- research.net wrote: Are there any open source libraries to connect to Streaming that use oAuth? -- M. Edward (Ed) Boraskyhttp://borasky-research.nethttp:// twitter.com/znmeb A mathematician is a device for turning coffee into theorems. - Paul Erdos
[twitter-dev] Re: Seeing weird, malformed HTTP responses? We're on it.
Any update on these messed up responses? I'm currently seeing users/ lookup.json responses get truncated if I request more than a small number of users. Hayes On Jul 19, 4:28 pm, jsleuth jsle...@gmail.com wrote: Yes indeed. It's a weird one. Thanks for the feedback. JS On Jul 19, 4:36 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, Along with a host of other issues we've been keeping you in the loop onhttp://status.twitter.com--we have another issue that a number of you have pointed out: *Our HTTP responses appear to be insane.* - We're sending Content-Length twice, with differing numbers -- and generally sending duplicate HTTP headers as a whole. - We're sending the incorrect Content-Type corresponding to the response format you are requesting (though the content itself is likely in the format you are expecting). - We're truncating response bodies. We've got the team looking into this right now. It's too early for an ETA on a fix. Thank you for your patience. This is, admittedly, a pretty weird issue. Taylor
Re: [twitter-dev] Re: strange search api behavior
+1 on this. I'm frequently getting 0 results from the search API (not an error, just 0 results) when including the since_id even though a search without the since_id shows that there are tweets with larger ids for the same query string. Hayes On Mon, Nov 23, 2009 at 1:16 AM, Karthik fermis...@gmail.com wrote: I have this problem as well. I use since_id and I query for newer results every minute. For past 10 days, I'm seeing my app was not indexing many tweets. I compared the results with search.twitter.com and I can clearly see that I'm missing out a lot of tweets, if I keep including the since_id parameter. I guess, there are some issues in the search system. On Nov 19, 3:30 am, Tadeu Andrade tadeu.andr...@gmail.com wrote: hi folks, since last week, I noticed thatsearchis behaving a little strange. For example, if I do a query on a keyword using since_id, sometimes I get no results. If I remove since_id parameters, the query succeed and if I repeat the initial query (with since_id), then I get results. Same thing occurs if I query from the web page and later from API (via json). Anyone else has noticed this weird behavior? cheers Tadeu
[twitter-dev] Re: API Calls During DoS Attack
I'm also seeing this same behavior for my whitelisted production IPs for CheapTweet.com and TweetReach.com. (Those were whitelisted under the @CheapTweet and @appozite accounts, respectively.) It works in development, but no requests are getting through to twitter.com on our production servers. I know you all have a lot on your plate right now but let us know what we can do to get un-blocked. Hayes -- Hayes Davis Founder, Appozite http://cheaptweet.com http://tweetreach.com On Thu, Aug 6, 2009 at 3:56 PM, Mario Menti mme...@gmail.com wrote: Thanks Alex - just to confirm, no requests from twitterfeed have been getting though ever since the DOS attack. It does appear to be IP based, as requests from non-production machines (ironically the non-whitelisted IPs) get through, but all production IPs appear to be blocked. On Thu, Aug 6, 2009 at 9:40 PM, Alex Payne a...@twitter.com wrote: We're talking to our operations team about it, who in turn is talking to our hosting provider. It seems that some aggressive IP filtering may have been catching some web-based third-party Twitter applications, as well as data centers used by mobile providers. On Thu, Aug 6, 2009 at 12:52, Jonathantwitcaps.develo...@gmail.com wrote: I would also appreciate an answer to this question. My calls to the Search API are failing because of circular redirection, and curl http://twitter.com returns nothing at all from my production server, which seems like a sign that its IP has been blocked. My app works fine from my dev box. -jonathan On Aug 6, 1:35 pm, Dewald Pretorius dpr...@gmail.com wrote: Chad, I know it's a little late in asking, but should we switch off cron jobs that make a lot of API calls while this DoS is going on, or while you are recovering from it? I don't want my IP addresses to be blocked because they are making a lot of calls! I've seen in the past that Ops lay down carpet bombing with cluster munitions when under attack. Will it help you to recover if we switched off the cron jobs? Right now most of my connections are just being refused. Do you guys at least check against the list of white listed IP addresses before you block an IP address in times like these? Will there be innocent bystanders caught in the cross-fire again? This is the kind of info that we developers need... Dewald -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Changing domains for image hosting
Are you going to shut off the S3 URLs immediately or will they still be accessible for a time? I understand that newly updated avatar images would not be updated at S3 after the switch but I'd like to know when we can expect any S3 URLs we may have in our caches to all go dark. Thanks. Hayes On Thu, Jul 9, 2009 at 8:53 AM, Clint Shryock cts...@gmail.com wrote: I'm still having issues with the profile_image_url attribute of users/show updating in a timely fashion, any chance this issue be resolved with this update? +Clint On Wed, Jul 8, 2009 at 11:55 PM, Doug Williams d...@twitter.com wrote: Andrew Stone asked a great question off list and I wanted to share the answer here. Images will be hosted from a number of sub-domains of twimg.com. Therefore you should not expect all images to be served from a0.twimg.comas in the examples provided, but instead should expect an aribitrary sub-domain (*.twimg.com). Thanks, Doug On Jul 8, 2009, at 6:20 PM, Doug Williams d...@twitter.com wrote: Folks -- We are going to be moving images to a new domain ( http://twimg.com twimg.com) to streamline our image hosting and offer better performance. We hope this will have limited impact as will only change the image URL. Example URLs include: Profile images: http://s3.amazonaws.com/twitter_production/profile_images/35240332/2929920.gif http://s3.amazonaws.com/twitter_production/profile_images/35240332/2929920.gif http://a0.twimg.com/profile_images/35240332/2929920.gif http://a0.twimg.com/profile_images/35240332/2929920.gif Background images: http://s3.amazonaws.com/twitter_production/profile_background_images/18156348/jessica_tiled.jpg.jpeghttp://s3.amazonaws.com/twitter_production/profile_background_images/18156348/jessica_tiled.jpg.jpeg http://a0.twimg.com/profile_background_images/18156348/jessica_tiled.jpg.jpeghttp://a0.twimg.com/profile_background_images/18156348/jessica_tiled.jpg.jpeg Thanks, Doug
[twitter-dev] Re: Changing domains for image hosting
I really appreciate it, Doug. Thanks. Hayes On Thu, Jul 9, 2009 at 4:43 PM, Doug Williams d...@twitter.com wrote: I've asked the operation's teams to leave the old S3 hosted images available for 2 weeks after the deploy. This should give you time to update your caches. Cheers, Doug On Thu, Jul 9, 2009 at 6:09 AM, Hayes Davis ha...@appozite.com wrote: Are you going to shut off the S3 URLs immediately or will they still be accessible for a time? I understand that newly updated avatar images would not be updated at S3 after the switch but I'd like to know when we can expect any S3 URLs we may have in our caches to all go dark. Thanks. Hayes On Thu, Jul 9, 2009 at 8:53 AM, Clint Shryock cts...@gmail.com wrote: I'm still having issues with the profile_image_url attribute of users/show updating in a timely fashion, any chance this issue be resolved with this update? +Clint On Wed, Jul 8, 2009 at 11:55 PM, Doug Williams d...@twitter.com wrote: Andrew Stone asked a great question off list and I wanted to share the answer here. Images will be hosted from a number of sub-domains of twimg.com. Therefore you should not expect all images to be served from a0.twimg.com as in the examples provided, but instead should expect an aribitrary sub-domain (*.twimg.com). Thanks, Doug On Jul 8, 2009, at 6:20 PM, Doug Williams d...@twitter.com wrote: Folks -- We are going to be moving images to a new domain ( http://twimg.com twimg.com) to streamline our image hosting and offer better performance. We hope this will have limited impact as will only change the image URL. Example URLs include: Profile images: http://s3.amazonaws.com/twitter_production/profile_images/35240332/2929920.gif http://s3.amazonaws.com/twitter_production/profile_images/35240332/2929920.gif http://a0.twimg.com/profile_images/35240332/2929920.gif http://a0.twimg.com/profile_images/35240332/2929920.gif Background images: http://s3.amazonaws.com/twitter_production/profile_background_images/18156348/jessica_tiled.jpg.jpeghttp://s3.amazonaws.com/twitter_production/profile_background_images/18156348/jessica_tiled.jpg.jpeg http://a0.twimg.com/profile_background_images/18156348/jessica_tiled.jpg.jpeghttp://a0.twimg.com/profile_background_images/18156348/jessica_tiled.jpg.jpeg Thanks, Doug
[twitter-dev] Odd Search Issue with Since and From Parameters
Guys, Something odd is going on with search when I use the since and from parameters together. Specifically something's up with June 25th. This page and the corresponding JSON-formatted API call both return an HTML-formatted 404 response: http://search.twitter.com/search?q=from%3Ahayesdavis+since%3A2009-06-25 This one http://search.twitter.com/search?q=from%3Ahayesdavis+since%3A2009-06-24 and this one http://search.twitter.com/search?q=from%3Ahayesdavis+since%3A2009-06-26 do not. This seems to happen with any from:username for that date. It doesn't happen for other dates. It also only happens if I use from and since together. If I use each independently, no problems. Should I file a bug? Hayes -- Hayes Davis Founder, Appozite http://cheaptweet.com http://tweetreach.com
[twitter-dev] Re: from and since_id 404 issues
Sounds related to my earlier post[1] about issues using from and since (as opposed to since_id). Hayes http://groups.google.com/group/twitter-development-talk/browse_thread/thread/2960bcdf84fef6d6 On Mon, Jun 29, 2009 at 8:36 PM, primedynasty primedyna...@gmail.comwrote: I am having issues using 'from' and 'since_id' resulting in 404 errors. There should be results and it certainly isn't a matter of being outside the Search time limit. an example: http://search.twitter.com/search?q=since_id=2147483647from=iHateRyanB should return some results. I believe this is a bug, but it would be nice if there was some notification that the id is out of the scope of search, or that we could search through a user's timeline.
[twitter-dev] Re: Bad Celebrity Search Results
I'm also curious about this phenomenon. It does seem that certain high-profile users are indexed poorly in search. It doesn't seem to correlate exactly with follower numbers but I've not done much in the way of empirical analysis on that. It's causing me some trouble on tweetreach.com as I often get requests to run reach reports about things tweeted by high profile users only to find that tweets from those users aren't returned by search. Should I file an issue for this? Hayes On Tue, May 12, 2009 at 1:54 PM, rob robsew...@gmail.com wrote: Hi, I'm doing a project that deals specifically with P Diddy (twitter.com/ iamdiddy). When I do a search, no tweets newer than May 6th show up. However, looking at his timeline, more recent tweets exist. This isn't a problem with my tweets (twitter.com/robseward). Also, it appears search is not returning accurate results for other celebrities online. Does anyone know what's going on here? Is the problem isolated to users with a high number of followers or is it something non celebrity- related. Some examples below: P Diddy: http://search.twitter.com/search?q=from%3Aiamdiddy http://twitter.com/iamdiddy Ashton Kutcher: http://search.twitter.com/search?q=from%3Aaplusk http://twitter.com/aplusk Shaq: http://search.twitter.com/search?q=from=THE_REAL_SHAQ twitter.com/THE_REAL_SHAQ Me (not a celebrity. Accurate search results). http://search.twitter.com/search?q=+from%3Arobseward twitter.com/robseward Rob
[twitter-dev] It looks like timelines and search are stuck
Guys, I don't see any notice on the status blog or other official channels so I figured I might as well say something. None of my account timelines have updated in more than 45 minutes and all search queries I'm looking at are that old as well. Hayes
[twitter-dev] New Ruby Twitter API Library: Grackle
Hi all, Just wanted to let everyone know that I've released a new Ruby Twitter API library called Grackle. It's at http://github.com/hayesdavis/grackle It works with both the search and REST APIs and supports both basic and OAuth authentication. The main thing that sets it apart is that it's designed to be resilient in the face of changes to the API. Everything's dynamic, so new API methods, changes to parameters or modifications to returned data don't require changes to the library itself. That has been quite helpful in my projects (and others that use it as well) as the guys move forward very quickly with new API functionality. Would it be possible to have it included among the available libraries on the wiki? Please let me know if you have any feedback, suggestions for improvement, etc. Thanks. Hayes Davis @hayesdavis
[twitter-dev] Re: OAuth and update_profile_image
I wanted to resurrect this because I didn't see an official response in the thread. I do see a response (as of yesterday) on the related support issue[1] but I wanted to verify a couple things. According to this response on the OAuth GetSatisfaction[2] page, Blaine says that multipart forms don't require that form parameters be included in the OAuth signature. However, when I try to post to either account/update_profile_image or account/update_profile_background_image using OAuth without including the params in the signature, I get back a not authenticated status. Is it planned for this to work in the future *or* should this work now and I'm just doing something wrong? If it should work, then I'll happily send along my headers, etc. [1] http://code.google.com/p/twitter-api/issues/detail?id=368 [2] http://getsatisfaction.com/oauth/topics/can_oauth_be_used_for_file_upload#reply_563569 Thanks. Hayes -- Hayes Davis @hayesdavis On Thu, Mar 19, 2009 at 3:11 PM, Luke l...@codegent.com wrote: I have exactly the same problem. How can we update images with OAuth? Agree that base64 encoded would be a good workaround for now. - Luke @luke_bkk On Mar 18, 8:55 pm, Zachary West zacw...@gmail.com wrote: Hi, It seems OAuth doesn't support multipart/form-data, at least this version of the OAuth spec doesn't support it. Would it be possible to also accept a base64-encoded, hashed (regular) argument for the image in the POST data instead of just the form-data submission/version? This would make it significantly easier to submit the data, if at all. Zachary West @zacwest
[twitter-dev] Re: friendships/exists broken?
I'm seeing the same thing. It's returning true for me no matter what when I make the call in the way Pierre describes. It also seems to be returning the raw true in the response body like it used to instead of the JSON repsonse I thought it was changed to back in January. Hayes -- http://cheaptweet.com On Mon, Feb 23, 2009 at 9:39 PM, pierre pomid...@gmail.com wrote: Hello, This API call is returning true while twitter.com shows that user_a is NOT following user_b: http://twitter.com/friendships/exists.json?user_a=749963user_b=14720560 Verified using curl providing user_a's username/password to authenticate the call. Just noticed about an hour ago. --Pierre
[twitter-dev] Re: friendships/exists broken?
Further investigation shows the XML format is working fine. Seems to be a problem only with the JSON version. Hayes -- http://cheaptweet.com
