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.


___ 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 <> 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 :("
> 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

Reply via email to