[twitter-dev] Re: Combining multiple API Searches into the Streaming API
Thanks for the feedback. Implementing the API was a lot easier then expected, my code is rather modular, so replacing the search component is easy. I only need one more step that actually breaks down the single stream output into matches per search I want to do. While it's an extra step in my process it's not a big deal in the end.
[twitter-dev] Re: Combining multiple API Searches into the Streaming API
I'll second Dewald's advice with one caveat. If you ever expect your search results to increase to a point where you're getting regular rate limiting (as :) and :( can certainly do that), I'd recommend looking into the Streaming API now. You'll have to add a lot of extra parsing and joining on your end, but it's the only way for your app to scale past the rate-limit point. If the app is simple, the collection volume isn't large, and you don't mind loosing tweets, the search api is way easier. On the other hand, you have to deal with all the additional logic for polling, handling rate limits, etc... you could put that effort into working on the merge operations for use with the raw streaming api. Jason (@jmstriegel) On Feb 2, 4:06 pm, Dewald Pretorius dpr...@gmail.com wrote: Ronald, In my opinion, if: a) You don't so much care about getting every single tweet that contains the keywords, but can live with the tweets being filtered and ranked for relevance (not a bad thing at all); b) You don't mind now and again getting a rate limit error; and c) You have search needs that the Streaming API does not satisfy, such as NEAR: and others. Then ___ continue to use the Search API For some uses, the Streaming API is a perfectly square hole. Don't try and force a round peg down the square hole. On Feb 2, 4:52 pm, Ronald ronald.bradf...@gmail.com wrote: I'm presently migrating some of my code base to the Streaming API, and I have a question regarding the filter/track syntax. Currently I run multiple searches on frequencies from 1 minute to 1 hour (based on output volume). Let's say for example the following 2 searches. happy OR sad and :) OR :( http://search.twitter.com/search?q=happy+OR+sadhttp://search.twitter With the streaming API filter and only one connection, it seems my only option is to combine these in to one filter i.e. track=happy,sad,:),:( I'm then required to do my own parsing to determine the actual source of the result. Hopefully I'm missing something here and I can separate track input and better identify the right result for the right search. Any help appreciated. Ronald
[twitter-dev] Re: Combining multiple API Searches into the Streaming API
Your assumption is correct. You'll have to do your own parsing. On Feb 2, 12:52 pm, Ronald ronald.bradf...@gmail.com wrote: I'm presently migrating some of my code base to the Streaming API, and I have a question regarding the filter/track syntax. Currently I run multiple searches on frequencies from 1 minute to 1 hour (based on output volume). Let's say for example the following 2 searches. happy OR sad and :) OR :( http://search.twitter.com/search?q=happy+OR+sadhttp://search.twitter.com/search?q=%3A%29+OR+%3A%28 With the streaming API filter and only one connection, it seems my only option is to combine these in to one filter i.e. track=happy,sad,:),:( I'm then required to do my own parsing to determine the actual source of the result. Hopefully I'm missing something here and I can separate track input and better identify the right result for the right search. Any help appreciated. Ronald
[twitter-dev] Re: Combining multiple API Searches into the Streaming API
Ronald, In my opinion, if: a) You don't so much care about getting every single tweet that contains the keywords, but can live with the tweets being filtered and ranked for relevance (not a bad thing at all); b) You don't mind now and again getting a rate limit error; and c) You have search needs that the Streaming API does not satisfy, such as NEAR: and others. Then ___ continue to use the Search API For some uses, the Streaming API is a perfectly square hole. Don't try and force a round peg down the square hole. On Feb 2, 4:52 pm, Ronald ronald.bradf...@gmail.com wrote: I'm presently migrating some of my code base to the Streaming API, and I have a question regarding the filter/track syntax. Currently I run multiple searches on frequencies from 1 minute to 1 hour (based on output volume). Let's say for example the following 2 searches. happy OR sad and :) OR :( http://search.twitter.com/search?q=happy+OR+sadhttp://search.twitter.com/search?q=%3A%29+OR+%3A%28 With the streaming API filter and only one connection, it seems my only option is to combine these in to one filter i.e. track=happy,sad,:),:( I'm then required to do my own parsing to determine the actual source of the result. Hopefully I'm missing something here and I can separate track input and better identify the right result for the right search. Any help appreciated. Ronald
