[twitter-dev] Re: Streaming API Rate Limiting

[Colin Surprenant]

Well, first, In the Gnip Power Track documentation
http://docs.gnip.com/w/page/35663947/Power-Track at the "has:geo"
section they say <>.

Also, I ran some tests a few weeks ago to see the difference in
content between the search api and the streaming api for equivalent
geolocalized searches. See this thread
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/a4bf3b7c6373657b#

My results showed that the streaming API returns a very small fraction
(3% in my tests) of what the search API returns. This is because the
streaming API only uses the geotagging API to locate tweets, but the
search API uses both the geotagging API and the user location field.

For example, I can get around 250 000 tweets/day for San Francisco
using the search api but the streaming api will return around 7000
tweets/day.

At 7000 tweets/day for San Francisco, 50 000 for the whole US seems
small.

Colin

On Apr 1, 2:40 pm, Augusto Santos  wrote:
> Sorry Colin, but where did you get this information? Doesn't match with the
> reality. Not at all.
>
> On Fri, Apr 1, 2011 at 12:35 PM, Colin Surprenant <
>
>
>
>
>
>
>
>
>
> colin.surpren...@gmail.com> wrote:
> > As a side note, currently only 3-4% of the total tweets (firehose) are
> > geo-tagged and are eligible to be selected in a stream location
> > bounding box. If the current firehose rate is about 140M tweets/day,
> > that makes ~5M eligible tweets/day.
>
> > I do not know what the proportion of tweets from the US is but I would
> > think 50% seem reasonable and would result in ~2.5M tweets/day. Even
> > if we lower that proportion, your 50 000 tweets/day seems way off.
>
> > There are 3 possibilities, 1) you are being rate limited more than you
> > think, 2) your bounding box is wrong or 3) your bounding box is too
> > large and Twitter has reduced it somehow. I remember I read somewhere
> > in the api doc that each bounding box could not be more than 1 degree
> > square "enough to cover most metropolitan areas" - but I cannot find
> > that back.
>
> > Colin
>
> > On Mar 31, 4:08 pm, Data Gatherer  wrote:
> > > We have a bounding box set for the United States. Even though it's a
> > > large box, we only receive about 50,000 tweets a day. However, I see
> > > that we get rate limited at least once a week already. The box is
> > > large, but the number of matching results is fairly low.  Knowing how
> > > the rate limiting works more specifically would be important when
> > > trying to gather data for other projects (more bounding boxes, other
> > > keywords).
>
> > > On Mar 31, 3:50 pm, Jeremy Dunck  wrote:
>
> > > > On Thu, Mar 31, 2011 at 2:48 PM, Augusto Santos 
> > wrote:
> > > > > No it won't. Streaming has rate limit with around 1% of firehose, if
> > your
> > > > > search term os too much generic.
> > > > > If your search term or bouding box get too many tweets, you will
> > start
> > > > > receive 'limit' status message as doc said.
> > > > >http://dev.twitter.com/pages/streaming_api_concepts#parsing-responses
>
> > > > Sure, I understand that, I just meant to say that 1% of all tweets is
> > > > a lot (140M average per day now).
>
> > > > If your terms are not very general, you have a lot of head room.
>
> > --
> > Twitter developer documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Issues/Enhancements Tracker:
> >http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this group:
> >http://groups.google.com/group/twitter-development-talk
>
> --
> 氣

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Re: Streaming API Rate Limiting

[Colin Surprenant]

As a side note, currently only 3-4% of the total tweets (firehose) are
geo-tagged and are eligible to be selected in a stream location
bounding box. If the current firehose rate is about 140M tweets/day,
that makes ~5M eligible tweets/day.

I do not know what the proportion of tweets from the US is but I would
think 50% seem reasonable and would result in ~2.5M tweets/day. Even
if we lower that proportion, your 50 000 tweets/day seems way off.

There are 3 possibilities, 1) you are being rate limited more than you
think, 2) your bounding box is wrong or 3) your bounding box is too
large and Twitter has reduced it somehow. I remember I read somewhere
in the api doc that each bounding box could not be more than 1 degree
square "enough to cover most metropolitan areas" - but I cannot find
that back.

Colin

On Mar 31, 4:08 pm, Data Gatherer  wrote:
> We have a bounding box set for the United States. Even though it's a
> large box, we only receive about 50,000 tweets a day. However, I see
> that we get rate limited at least once a week already. The box is
> large, but the number of matching results is fairly low.  Knowing how
> the rate limiting works more specifically would be important when
> trying to gather data for other projects (more bounding boxes, other
> keywords).
>
> On Mar 31, 3:50 pm, Jeremy Dunck  wrote:
>
>
>
>
>
>
>
> > On Thu, Mar 31, 2011 at 2:48 PM, Augusto Santos  wrote:
> > > No it won't. Streaming has rate limit with around 1% of firehose, if your
> > > search term os too much generic.
> > > If your search term or bouding box get too many tweets, you will start
> > > receive 'limit' status message as doc said.
> > >http://dev.twitter.com/pages/streaming_api_concepts#parsing-responses
>
> > Sure, I understand that, I just meant to say that 1% of all tweets is
> > a lot (140M average per day now).
>
> > If your terms are not very general, you have a lot of head room.

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Re: Search API rate limit change?

[Colin Surprenant]

By adjusting the rate limits to reduce the stress on your search api
without notice you have significantly increased the stress level on
our end :P Seriously, advanced notice of the situation would have been
welcome.

In particular what created lots of confusion on our end is that even
after pausing for the specified "retry_after" delay we would
immediately get repeated 420s at which point we started to assume our
IPs were banned (which also contributed to increase the stress level).

Colin

On Mar 21, 9:12 am, Jeffrey Greenberg 
wrote:
> Taylor,
> Yeah this was definitely NOT good.    In the past, when there is a
> service disruption, your api group would post something on your status
> page and tweet about it... Instead, I'm finding out about this from my
> customers...
>
> Did y'all tweet about this or present this somewhere where I could find it?
>
> Jeffrey
> Tweettronics.com
>
> On Sun, Mar 20, 2011 at 3:14 PM, Waldron Faulkner
>
>
>
>
>
>
>
>  wrote:
> > Without prior notice, I can understand (circumstances), but without
> > any kind of subsequent announcement?? Means we have to discover issues
> > ourselves, verify that they're Twitter related (and not internal),
> > then search around for existing discussion on the topic. Saves us a
> > lot of time and headaches if Twitter would just announce stuff like
> > this.
>
> > On Mar 18, 2:51 pm, Taylor Singletary 
> > wrote:
> >> We're working to reinstate the usual limits on the Search API; due to the
> >> impact of the Japanese earthquake and resultant query increase against the
> >> Search API, some rates were adjusted to cope & better serve queries. Will
> >> give everyone an update with the various limits are adjusted.
>
> >> @episod  - Taylor Singletary - Twitter Developer
> >> Advocate
>
> >> On Fri, Mar 18, 2011 at 11:39 AM, Hayes Davis  wrote:
> >> > Hi,
>
> >> > We're seeing this as well starting at approximately the same time as
> >> > described. We've backed off on searching but are seeing no reduction in 
> >> > the
> >> > sporadic limiting. It also appears that the amount of results returned on
> >> > successful queries is severely limited. Some queries that often have 1500
> >> > tweets from the last 5 days are returning far fewer results from only the
> >> > last day.
>
> >> > Could we get an update on this?
>
> >> > Hayes
>
> >> > On Fri, Mar 18, 2011 at 10:13 AM, Eric  wrote:
>
> >> >> We're also seeing 400s on different boxes across different IP
> >> >> addresses with different queries (so it does not appear to be server
> >> >> or query specific). These began on all boxes at 2 a.m. UTC. We've
> >> >> backed off on both number and rate of queries with no effect. We've
> >> >> also noticed an increase in sporadic fail whales via browser based
> >> >> search (atom and html) from personal accounts, although we haven't
> >> >> attempted to quantify it.
>
> >> >> On Mar 18, 7:40 am, zaver  wrote:
> >> >> > Hello,
>
> >> >> > After the latest performance issues with the search api i have been
> >> >> > seeing a lot of 420 response codes.From yesterday until now i only get
> >> >> > 420 responses on the every search i make. In particular, i search for
> >> >> > about 100 keywords simultaneously every 6 mins. Why is this happening?
> >> >> > Was there any change on the Search API limit?
>
> >> >> > Any help is greatly appreciated.
>
> >> >> > Thanks,
> >> >> > Zaver
>
> >> >> --
> >> >> Twitter developer documentation and resources:http://dev.twitter.com/doc
> >> >> API updates via Twitter:http://twitter.com/twitterapi
> >> >> Issues/Enhancements Tracker:
> >> >>http://code.google.com/p/twitter-api/issues/list
> >> >> Change your membership to this group:
> >> >>http://groups.google.com/group/twitter-development-talk
>
> >> >  --
> >> > Twitter developer documentation and resources:http://dev.twitter.com/doc
> >> > API updates via Twitter:http://twitter.com/twitterapi
> >> > Issues/Enhancements Tracker:
> >> >http://code.google.com/p/twitter-api/issues/list
> >> > Change your membership to this group:
> >> >http://groups.google.com/group/twitter-development-talk
>
> > --
> > Twitter developer documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Issues/Enhancements Tracker:http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this 
> > group:http://groups.google.com/group/twitter-development-talk

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Re: should search and streaming apis return similar tweets for equivalent geolocation areas

[Colin Surprenant]

Did not receive any answer on the questions below. I think it is
important for us developers to understand the direction Twitter is
taking in relation to geolocalized searches.

In a nutshell:

For geolocalized searches, the streaming API returns a very small
fraction (3% in my tests) of what the search API returns. This is
because the streaming API only uses the geotagging API to locate
tweets, but the search API uses both the geotagging API and the user
location field.

Depending on your application, both methods can be valuable. In
particular, what the search API retrieves make sense in my context but
it is not possible to get this using the streaming API.

- Can we expect both methods to be supported in the future and can we
expect to get a streaming version of what the search API does today?

Thanks,
Colin

On Feb 15, 2:19 pm, Colin Surprenant 
wrote:
> So basically today we have two options for geo search:
>
> - use the search api and get results that will include some
> incorrectly geolocalized tweets when falling back on the user location
> field.
> - use the streaming api and retrieve significantly far less tweets but
> with a higher degree of confidence in their geolocation using only the
> geotagging api.
>
> Can we expect these two methods to be available concurrently for the
> next 3, 6, 12 months?
>
> I have two problems with this:
>
> - As developers we are asked to migrate toward the streaming api
> instead of using periodic polling, which makes sense. But for geo
> search, the streaming api is not a viable alternative for those who
> actually prefer/require/want the behaviour of the geo search api.
>
> - The fact the the streaming api returns far less but more precise
> data is not necessarily better, it really depends who you ask. For me,
> having lots of geolocalized data that will contain a fraction of
> invalid data is far more valuable than having far less but more
> accurate data.
>
> My tests told me the streaming api currently returns only ~3% of the
> volume of data the search api produces. If the only difference between
> the search api and the streaming api is the usage of the user location
> field, then we can certainly say that FAR more people are still only
> using their user location field and not using the geotagging api.
>
> Will you offer an option in the streaming api to fall back or not on
> the user location field when evaluating the geolocation of a tweet?
>
> Thanks,
> Colin
>
> On Feb 14, 2:33 pm, Taylor Singletary 
> wrote:
>
>
>
>
>
>
>
> > Hi Colin,
>
> > You hit the nail on the head with this observation:
>
> > > In the doc it says that the streaming API will only return tweets that
> > > are created using the Geotagging API (and within the bounding box) but
> > > the search API will preferentially use the Geotagging API, but will
> > > fall back to the Twitter profile location.
>
> > The Search API is greedy with those location fields on user's
> > profiles. It's not likely this behavior will be emulated in the
> > Streaming API with the bright side that you can be more confident in
> > the location accuracy in matches on the Streaming API.
>
> > Thanks,
> > Taylor

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Re: should search and streaming apis return similar tweets for equivalent geolocation areas

[Colin Surprenant]

I did ran tests on keyword search and found only very marginal
differences between polling the search api and using the streaming
api. I also followed up in your thread.

Colin

On Feb 15, 2:39 pm, Karussell  wrote:
> Hmmh, would you mind to test this without the geo location filter?
> And report your findings here? I'm having an issue even with that.
> See:
>
> http://groups.google.com/group/twitter-development-talk/browse_thread...
>
> Kind Regards,
> Peter.
>
> --
>
> http://jetwick.comTwitter Search without Noise

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Re: Streaming API vs. Search API: no API returns >95% of intented tweets

[Colin Surprenant]

First your test set is a bit small. Did you take into account the
extra data you will get in your first search api poll? Typically your
first poll will return 100 items then subsequent polls will return
only "new" data if using since_id and/or dedupping.

Make sure both your poller and stream reader start at the same item. A
trick, if you want to grab as much similar results at possible from
the start is to request only a single item on the first poll (using
rpp=1) (or use only the most recent item of your result) then use this
item to seed your since_id on the following polls. Another idea might
be to start your stream reader first and use the first item returned
by your reader to again seed your since_id in your poller. Also you
can simply ignore this during collection but cleanup your data once
your done collecting and make sure both data sets start and end with
the same item ID.

In any case, if your difference is in fact related to the handling of
the first poll, it will become marginal as your data grow.

I also ran some tests to compare results between both methods using a
single keyword. With result sets of about 15000 ids, both sets are
identical at 98.3%. For testing purposes both my poller and stream
reader only output IDs so I can use cat, sort, uniq, wc and diff to
compare results.

Colin

On Feb 15, 2:33 pm, Karussell  wrote:
> Hi John, hi Adam,
>
> thanks for your responses.
>
> > To increase recall, search sometimes includes keywords in followed links 
> > and other techniques
>
> ah, ok. this would explain the differences between C and B (but not
> betweet C and A). I'll investigate ...
>
> > Also, are you getting rate limit messages on the Streaming API?
>
> no.
> I saw track limits (or something) when my keyword was 'java' or a
> similar high frequent term.
>
> Regards,
> Peter.
>
> On 15 Feb., 18:30, John Kalucki  wrote:
>
>
>
>
>
>
>
> > If you examine set C, do they contain matches on fields other than the Tweet
> > text? To increase recall, search sometimes includes keywords in followed
> > links and other techniques.
>
> > Also, are you getting rate limit messages on the Streaming API?
>
> > -John Kaluckihttp://twitter.com/jkalucki
> > Twitter, Inc.
>
> > On Tue, Feb 15, 2011 at 3:36 AM, Karussell 
> > wrote:
>
> > > Hi,
>
> > > this problem was already posted to the twitter4j mailing list [1]. Not
> > > sure if it is an issue with my code, twitter4j or an API issue... user
> > > reported similar problems in the past [2].
>
> > > First:
>
> > > I'm doing a 100 tweet search (without paging) every 5 minutes e.g.
> > > against 'twitter search'. I get a set of tweets A - excluding the
> > > duplicates, of course. I get approx 5 new tweets for every 5 minutes,
> > > so 100 tweets as pageSize should be perfectly sufficient to get all
> > > tweets.
>
> > > Second:
> > > When I'm doing a streaming filter request for the same terms 'twitter
> > > search' then I'm getting a set of tweets B.
>
> > > The problem is: combining A and B ('C=A v B') gives me a set C where
> > > the count of C is more than 10% larger then A or B, which means that
> > > neither with search nor streaming API I can catch a nearly complete
> > > set of tweets.
>
> > > E.g. doing this for 3 hours I'm getting 254 tweets (A) for the search
> > > and 257 tweets (B) for the streaming but the combined set C has 337
> > > tweets!
>
> > > Is this a bug in my code or could this be an API issue?
>
> > > BTW: I don't assume 100% correctness, I only want something above
> > > 90% :) especially for such relatively infrequent terms, where users
> > > can, should and have noticed it.
>
> > > Regards,
> > > Peter.
>
> > > [1]
> > >http://groups.google.com/group/twitter4j/msg/d959e6257ceb452f
>
> > > [2]
>
> > >http://groups.google.com/group/twitter-development-talk/browse_thread...
>
> > >http://blog.tweetsmarter.com/twitter-downtime/twitters-dirty-secret-t...
>
> > > --
>
> > >http://jetwick.comTwitterSearch without Noise
>
> > > --
> > > Twitter developer documentation and resources:http://dev.twitter.com/doc
> > > API updates via Twitter:http://twitter.com/twitterapi
> > > Issues/Enhancements Tracker:
> > >http://code.google.com/p/twitter-api/issues/list
> > > Change your membership to this group:
> > >http://groups.google.com/group/twitter-development-talk

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Re: should search and streaming apis return similar tweets for equivalent geolocation areas

[Colin Surprenant]

So basically today we have two options for geo search:

- use the search api and get results that will include some
incorrectly geolocalized tweets when falling back on the user location
field.
- use the streaming api and retrieve significantly far less tweets but
with a higher degree of confidence in their geolocation using only the
geotagging api.

Can we expect these two methods to be available concurrently for the
next 3, 6, 12 months?

I have two problems with this:

- As developers we are asked to migrate toward the streaming api
instead of using periodic polling, which makes sense. But for geo
search, the streaming api is not a viable alternative for those who
actually prefer/require/want the behaviour of the geo search api.

- The fact the the streaming api returns far less but more precise
data is not necessarily better, it really depends who you ask. For me,
having lots of geolocalized data that will contain a fraction of
invalid data is far more valuable than having far less but more
accurate data.

My tests told me the streaming api currently returns only ~3% of the
volume of data the search api produces. If the only difference between
the search api and the streaming api is the usage of the user location
field, then we can certainly say that FAR more people are still only
using their user location field and not using the geotagging api.

Will you offer an option in the streaming api to fall back or not on
the user location field when evaluating the geolocation of a tweet?

Thanks,
Colin

On Feb 14, 2:33 pm, Taylor Singletary 
wrote:
> Hi Colin,
>
> You hit the nail on the head with this observation:
>
> > In the doc it says that the streaming API will only return tweets that
> > are created using the Geotagging API (and within the bounding box) but
> > the search API will preferentially use the Geotagging API, but will
> > fall back to the Twitter profile location.
>
> The Search API is greedy with those location fields on user's
> profiles. It's not likely this behavior will be emulated in the
> Streaming API with the bright side that you can be more confident in
> the location accuracy in matches on the Streaming API.
>
> Thanks,
> Taylor

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Re: should search and streaming apis return similar tweets for equivalent geolocation areas

[Colin Surprenant]

Some metrics:

I just reran some tests to compare results for both the polling search
api + geocode and the steaming api statuses/filter + locations using
San Francisco as the geolocation.

Basically, the polling search api+geocode returns approximately 30x
more results than the steaming api statuses/filter + locations within
the same test period for the same geolocation.

The parameters used for the search api+geocode were: 37.736784,
-122.44709, 40km
The parameters used for the steaming api statuses/filter + locations
were:
-122.901549008664,37.3773810096865,-121.992630991336,38.0961869903135
which correspond to the bounding box around 37.736784, -122.44709,
40km.

Why is there such huge difference and can we expect the streaming API
to eventually match what the search API produces for geolocalized
searches?

Thanks,
Colin

On Feb 10, 5:32 pm, Colin Surprenant 
wrote:
> Hi,
>
> I have been running some tests to gather tweets from users within a
> geo area using both the search API (with the geocode parameter) and
> the streaming API (with the statuses/filter method & locations
> parameter).
>
> I have noticed that the streaming API returns far less tweets for an
> equivalent area expressed either as a latlong+radius for the search
> API or as a bounding box for the streaming API.
>
> Is this normal or should we expect a similar result set with both
> methods?
>
> In the doc it says that the streaming API will only return tweets that
> are created using the Geotagging API (and within the bounding box) but
> the search API will preferentially use the Geotagging API, but will
> fall back to the Twitter profile location.
>
> Can this explain why I see much more results with the search API?
>
> Thanks,
> Colin

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] should search and streaming apis return similar tweets for equivalent geolocation areas

[Colin Surprenant]

Hi,

I have been running some tests to gather tweets from users within a
geo area using both the search API (with the geocode parameter) and
the streaming API (with the statuses/filter method & locations
parameter).

I have noticed that the streaming API returns far less tweets for an
equivalent area expressed either as a latlong+radius for the search
API or as a bounding box for the streaming API.

Is this normal or should we expect a similar result set with both
methods?

In the doc it says that the streaming API will only return tweets that
are created using the Geotagging API (and within the bounding box) but
the search API will preferentially use the Geotagging API, but will
fall back to the Twitter profile location.

Can this explain why I see much more results with the search API?

Thanks,
Colin

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Re: language and geocode problem

[Colin Surprenant]

Currently it looks like any geo based search queries are returning
zero result.
ex, on New York: 
http://search.twitter.com/search.json?geocode=40.739454,-73.883743,75km

The question is: what is the expected timeframe for a fix on this?
hours, days, weeks?
They only say "Engineering working on a fix". See

https://twitter.com/#!/twitterapi/status/9262744515645440
http://twitter.com/#!/twitterapi/status/9636345710379008

Colin

On Nov 30, 8:27 am, mazz  wrote:
> Hi,
> has somebody noticed that there are problems filtering the search with
> language and geocode?
>
> This search gives only few tweets or 
> nothing:http://search.twitter.com/search.atom?lang=en&q=me
>
> and with italian ther's no way to get 
> results:http://search.twitter.com/search.atom?lang=it&q=calcio
>
> thanks
> Mazz

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Re: statuses/filter streaming api vs Gnip announcement

[Colin Surprenant]

bump - anyone?

On Nov 17, 4:16 pm, Colin Surprenant 
wrote:
> Hi,
>
> - does the usage of the statuses/filter method on the streaming api
> impacted by the Gnip announcement?
>
> - do we know the maximum rate (or approximation) allowed through the
> statuses/filter method? (incidentally, at which point in terms of rate
> we have to consider firehosing, therefore, Gnip options?
>
> Thanks,
> Colin

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] statuses/filter streaming api vs Gnip announcement

[Colin Surprenant]

Hi,

- does the usage of the statuses/filter method on the streaming api
impacted by the Gnip announcement?

- do we know the maximum rate (or approximation) allowed through the
statuses/filter method? (incidentally, at which point in terms of rate
we have to consider firehosing, therefore, Gnip options?

Thanks,
Colin

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk