[twitter-dev] Re: [twitter-api-announce] countdown to OAuth / basic auth removal / OAuthcalypse
Hey, What's the timeline like, if you know, for the streaming api? Thanks! ttyl Dima On Sat, Apr 24, 2010 at 8:40 AM, Raffi Krikorian wrote: > hi all. > > you're going to be hearing a lot from me over the next 9 weeks. our plan > is to turn off basic authorization on the API by june 30, 2010 -- developers > will have to switch over to OAuth by that time. between now and then, there > will be a *lot* of information coming along with tips on how to use OAuth > Echo, xAuth, etc. we really want to make this transition as easy as we can > for everybody. > > as always, please feel free to reach out to this group, or to @twitterapi > directly. if you need help remembering the date - > http://bit.ly/twcountdown. > > -- > Raffi Krikorian > Twitter Platform Team > http://twitter.com/raffi > > -- > Twitter API documentation and resources: http://apiwiki.twitter.com > API updates via Twitter: http://twitter.com/twitterapi > Change your membership to this group: > http://groups.google.com/group/twitter-api-announce?hl=en >
[twitter-dev] stream api query with both track and follow
Hi I have a question as to the behaviour when one specifies both a 'track' parameter and a 'follow' parameter. From my understanding from the wiki: statuses/filter Returns public statuses that match one or more filter predicates. At least one predicate parameter, follow, locations, or track must be specified. Multiple parameters may be specified which allows most clients to use a single connection to the Streaming API. Placing long parameters in the URL may cause the request to be rejected for excessive URL length. Use a POST request header parameter to avoid long URLs. Is that the parameters are treated as an 'or' clause and thus I would get everything, minus the usual limits, for a particular track predicate and everything for all the users I am following. Is this the correct interpretation. Also, if I was just following a track query and then I add a follow query, will the number of results in my track query go down because some amount is used up by the follow, or are the limits individually placed on track and on follow. Thanks! ttyl Dima -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
[twitter-dev] Stream API - determining access level
Hey, Quick question, is there any programatic way to determine the access level one has to the streaming api, in particular I want to find out my follow limit for the status filter. Thanks! ttyl Dima -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
Re: [twitter-dev] Streaming API OAuth explanation?
Hi, Question about oauth registration ... do I register the user ID I currently use at the same place as all other apps, i.e.http://dev.twitter.com/apps/new, or is there another endpoint for the streaming api? Thanks! ttyl Dima On Tue, Apr 20, 2010 at 10:17 AM, Taylor Singletary < taylorsinglet...@twitter.com> wrote: > Hi Jonathon, > > For Streaming API access that isn't from the perspective of a user's > account, you would use two-legged OAuth to establish authentication instead > of basic auth. > > A two-legged OAuth request is very similar to other OAuth requests: you > have a specific resource you are trying to access, you have some parameters > you want to pass to that resource, and you have an OAuth consumer key and > OAuth consumer secret. Which is unlike three-legged OAuth where you also > have oauth_tokens representing either a user/access_token or a request token > in addition to the rest. > > But the rules remain the same. You take all the OAuth parameters and the > parameters you are sending to the resource, organize them, build a signature > base string, then sign that with your consumer secret and send the request > on to Twitter properly signed. The only difference is that there is no > oauth_token and oauth_token_secret getting involved in the mix. > > This is essentially what a two-legged request to the streaming API would > look like: > > Signature Base String > GET&http%3A%2F%2Fstream.twitter.com > %2F1%2Fstatuses%2Fsample.json&oauth_consumer_key%3Dri8JxYK2zzwSV5xIUfNNvQ%26oauth_nonce%3DSJJqJPdaZrYuIogToapS6ueJRyWB4Rs2ox4HEbu4nW8%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1271783743%26oauth_version%3D1.0 > > Signature > Xi5jfuw2XqtU5KpNX9ZCtTptJS0= > > Authorization Header > OAuth oauth_nonce="SJJqJPdaZrYuIogToapS6ueJRyWB4Rs2ox4HEbu4nW8", > oauth_signature_method="HMAC-SHA1", oauth_timestamp="1271783743", > oauth_consumer_key="ri8JxYK2zzwSV5xIUfNNvQ", > oauth_signature="Xi5jfuw2XqtU5KpNX9ZCtTptJS0%3D", oauth_version="1.0" > > Taylor Singletary > Developer Advocate, Twitter > http://twitter.com/episod > > > On Tue, Apr 20, 2010 at 10:05 AM, Jonathon Hill wrote: > >> One thing I meant to find out @chirp last week--what will oauth look >> like for the Streaming API? I'm having a hard time visualizing how >> that will work. >> >> Thanks, >> >> Jonathon Hill >> @compwright >> Company52 >> http://company52.com >> >> >> -- >> Subscription settings: >> http://groups.google.com/group/twitter-development-talk/subscribe?hl=en >> > >
Re: [twitter-dev] Streaming API question
Hi, Yup, I saw it the last couple of weeks, this week has been considerably better. I use the delimited stream so I do read(entry size), read(entry), repeat ... I just put a 30 second timeout on the read operation (this is all in python) and if a read fails I close the stream and reconnect. This seems to work quite well ... depending on the chunk size you are reading you could probably lower the timeout if you are afraid of losing data. ttyl Dima On 19-Feb-10, at 7:36 AM, rob wrote: Has anyone else ran into an issue where over time the Streaming API just stops sending results? We are using a Ruby library to connect (twitter-stream) which uses EventMachine to open a persistent connection to the API (we are tracking and following). The library properly handles reconnection (from dropped connections) and the various error conditions. All works well for a period of time (8+ hours in some cases, sometimes a full day) after that the connection does no get dropped but no data gets sent. (At least that's what is seems as EventMachine feels its still connected) If we just drop the connection and reconnect all is well and the data starts to flow again. (Which we could do but that seems like a hack) Anyone else have this issue or should I dive into the EventMachine code and see if there is an issue in there? Thanks in advance, Rob -- ddbrod...@gmail.com "The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find the most hard to pay." (Sir Antony Hoare, 1980)
