On 2/19/11 2:23 PM, Paresh Nakhe wrote:
On going through the documentation in more detail i found this:

-> The the track parameter (keywords), and the location parameter (geo)
on the statuses/filter method are rate-limited predicates.
You can't have an infinite number of search terms.

-> After the */limitation period/* expires, all matching statuses will
once again be delivered, along with a limit message that enumerates the
total number of statuses that have been eliminated from the stream since
the start of the connection.
As far as I know, this limitation is only for user streams. When you get more than 2 or 3 statuses per second, it wouldn't be readable for the user anyway so the extra statuses get discarded and you get a limitation notice. I don't think that this goes for the "normal" stream.

What exactly is the limitation period and what is one supposed to do
after the limitation period expires? Destroy the current connection and
create a new one?
Just keep listening :-)


Paresh.

On Sat, Feb 19, 2011 at 6:22 PM, Tom van der Woerdt <i...@tvdw.eu
<mailto:i...@tvdw.eu>> wrote:

    On 2/19/11 1:49 PM, Paresh Nakhe wrote:

        Hi,
          From what i understand, there is no concept of rate limiting for
        streaming api. Actually it does make sense because if anyone is
        to use
        'statuses/sample' method (say) the limit will soon be crossed.
          We are
        working on something that will heavily use the streaming api, so
        if rate
        limiting is imposed in future it could create some problems.
          Are there
        any chances of such a restriction being imposed?

    There's no limit on the amount of tweets you can receive, but
    there's a limit on the amount of searches you can do, and the amount
    of connections you can have open.


        Secondly, this api requires authentication unlike search api.
        Authentication for user streams is fine but I don't understand
        it's need
        for streaming api.

    There's probably no real technical reason for why this is required,
    but for properly being able to keep statistics etc, it's needed.
    That, and the fact that there are several different "levels" of
    access to the API.


        Thanks,
        Paresh

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




--
/What I have is not a dream, because I will make it a reality./


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

Reply via email to