Thanks, Ryan!
I'm looking forward to Thursday's discussion. I think that as 3rd
party Twitter developers, we think of ourselves existing somewhere in
the highest bracket of engaged users. Whether it's a valid concern
remains to be proven, but a lot of folks (myself included) are now
wondering if
I have to fly out on Friday morning, but I'd love to participate in
the discussion. I'm still pretty new to the Twitter developer club,
but I'm really looking forward to meeting you all.
Jason
@jmstriegel
--
To unsubscribe, reply using remove me as the subject.
Thought I'd chime in here and add my support for Phrirehose - Fenn,
nice work!
We just did our first test-run with Phirehose on Sunday to track all
of the traffic related to Super Bowl ads. At peak, it was pulling a
consistent 120 tweets/sec with ease. We were only limited by our
account's
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
of
thousands of predicates. Opening many connections to theStreamingAPI
will appear like an attempt to circumvent existing rate limits and you
are likely to be banned from all twitter.com access.
-John Kaluckihttp://twitter.com/jkalucki
Infrastructure, Twitter Inc.
On Thu, Jan 28, 2010 at 6:15 PM, Jason
Is there any order or precedence to how tweets are selected for rate
limiting when using the streaming api with many (hundreds to
thousands) of filter predicates. I'm curious if rate limiting is
applied to the higher volume predicates in a filter, before it's
applied to lower volume ones.
We
We started running into rate limiting issues today with one of our
applications that uses the Search API (squawq.com). We're using it to
track user-defined queries for a bunch of folks and provide analytics
on those searches. It seems like developers are being asked to migrate
to the Streaming
The easy way is to use the search API with from:username as the query
term. It'll work for public tweets.
Ie. http://search.twitter.com/search.json?q=from%3Ajmstriegel
I'm currently hitting rate limit issues with the search api, though,
so if you're planning on doing this in high volume for lots
