Ronald,
In my opinion, if:
Advertising
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
