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