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
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 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
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
