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
