Thanks for the reply, I appreciate it.

I have concerns regarding the streaming APIs, which mainly concern the

* usage of logical OR when using locations
* firehose limitations
* the user’s location field is not used to filter tweets
* increased application complexity for parsing the resulting stream of
data back out into individual searches

I know that the Search API is not Twitter's preferred choice, but it's
currently returning the best applicable results for my application.
It's also worth noting that the API recently received a drastic
improvement to speed which should theoretically relax the strain on
the API:

I guess I'm mainly interested in knowing whether @twitterapi will
allow me to use the Search API in the manner I indicated above?
Essentially I would be willing to guarantee the application worker
nodes handles 420 rate limiting errors accordingly while still
supporting multiple twitter accounts and searches.

On Apr 11, 1:05 pm, "M. Edward (Ed) Borasky" <zn...@borasky-> wrote:
> I don't see an answer here, but I'll tell you how *I* would go about
> implementing this:
> 1. Switch to the Streaming API. Using Search in an application puts a strain
> on Twitter's servers and makes it difficult to Twitter to manage capacity.
> That's why it's rate-limited and why the rate limits aren't publicly
> disclosed.
> 2. If your application is a desktop application, use User Streams. If it is
> a server, use User Streams on a desktop or the low-frequency free access to
> Streaming on a server to prototype and develop. Your target for a server
> will be Site Streams, but that's in closed beta at the moment IIRC.
> 3. *Concurrently with development*, your business development / sales /
> marketing / planning people, or yourself, if it's a one-person shop, should
> be negotiating with Twitter for access to Site Streams, I'm assuming an
> "agile" development methodology - customer-in-the-loop - and one of the
> parties that needs to be in the loop is Twitter for Site Streams. You simply
> *can't* build an at-scale Twitter application without direct business
> discussions with Twitter!
> On Mon, Apr 11, 2011 at 8:14 AM, Corey Ballou <> wrote:
> > I tried speaking with Ryan Sarver directly, but he's forwarding me
> > here to the community advocates to answer. I believe this answer will
> > need to come top down from Twitter, as it's your rate limiting that
> > I'm most worried about.
> > I have a technical question for all of you in regards to the Search
> > API as I want to maintain full compliancy. Currently, the old Search
> > API implementation (albeit slower) provides a fuller result set and
> > allows for more flexibility in the types and combinations of searches
> > allowed. The manner I have developed my application would allow for a
> > number of daemonized worker instances running on different IP
> > addresses to make calls to the search API on behalf of the stored
> > OAuth credentials to avoid rate limiting issues.
> > I had a conversation with the Pluggio developer in which he stated
> > Twitter had threatened to shutdown his application if he didn't switch
> > to a different implementation of the Search API. The problem indicated
> > was that he was performing searches for multiple Twitter accounts,
> > which is exactly my use case. Site streams does not make as much sense
> > for my application given the search queries I wish to perform and the
> > necessity for logical AND operations on geo-location.
> > Do you foresee any problems with my current method of using different
> > IP addresses to stay under the rate limit? I'm trying to stay in full
> > compliance with Twitter's TOS and would love to find the most
> > applicable and API friendly solution. I know headway is being made
> > with Twitter's new search implementation so I would like to stay ahead
> > of the curve and not get myself stuck in a box.
> > I still need a method for polling for new search results (say, every
> > 30 minutes, dependent upon the pricing plan) for non-logged in users.
> > Below is a scaled down representation of how I'm currently handling
> > searches to help you decide the best plan of action:
> > 1) Searches are performed on a rolling queue basis, say one search
> > every thirty minutes. There can be a finite number of searches per
> > Twitter user (say 5 searches per Twitter account). There can be any
> > number of Twitter accounts.
> > 2) Search results are stored locally for retrieval by a javascript
> > AJAX long-poller every minute to check for frequent changes.
> > 3) When a user visits the search results page and filters results, no
> > API calls to Twitter are made, only a local query is required
> > Due to this process, the queue is constantly searching for the next
> > searches and mentions to perform. I foresee rate limiting concerns
> > cropping up with searches being performed for any number of users.
> > Can you steer me in the right direction to avoid shutdown notices or
> > access revocation?
> > Regards,
> > Corey
> > @cballou
> > --
> > Twitter developer documentation and resources:
> > API updates via Twitter:
> > Issues/Enhancements Tracker:
> >
> > Change your membership to this group:
> >
> --
> "A mathematician is a device for turning coffee into theorems." -- Paul
> Erdős

Twitter developer documentation and resources:
API updates via Twitter:
Issues/Enhancements Tracker:
Change your membership to this group:

Reply via email to