Hi,

Twitter is really a great tool for sharing and acquiring information.
Lately more and more people are starting to use it.  That’s good news
because it becomes a trustable medium for information exchange. But,
paradoxically, it is bad news as well. While the number of users is
significantly increasing so is the number of possible candidates
(users) to follow.

Empirical proof might help in understanding the problem:

Suppose the user X is following 1000 users (which is not a rare
situation)
Suppose those users post in average 5 tweets/ day (again, a situation
not hard to accept)
User X is busy, but every morning for a limited period of time reads
the tweets of his friends.
That is ~5000 tweets. He chooses to skim through them and if something
good pops up he’ll pay more attention to it.

At this moment the web site it’s not designed for this kind of
interaction.  Pushing the “More” button it’s just not so practical.
One may think that the API comes to rescue, but actually it
doesn’t.While it comes with some features, those are limited

The API is well suited for lightweight and mobile application where
the latest news is important. But for application that want to offer
some digging tools the API doesn’t offer much help. In the example
scenario the number of tweets accumulated in one day was ~5000 while
the limitation for the  /statuses/home_timeline is ( at least in the
documentation) 3200. The problem here is that this limitation was ok
in the past, but now when more and more users are interacting through
tweeter this limitation becomes a real bottleneck.

>From what I’ve understood the reason for this behavior is server
overloading. The servers can’t handle this amount of data.


The question:
Is there a way to grant access to more data for developers? If not
directly at least through some kind of request (like in the case of
Rate Limiting)

Thanks


On Jun 18, 11:36 pm, Taylor Singletary <taylorsinglet...@twitter.com>
wrote:
> Hi Folks,
>
> Many of you have noticed incorrect counts of how many tweets a given user
> has. In addition, you've noticed that statuses/user_timeline is only
> allowing around ~800 statuses to be returned in total. These issues should
> be resolved by the end of next week -- we'll be rebuilding the cached
> representations of these timelines and users which will repair the issue.
> This process takes some time and will be gradual and incremental.
>
> After consulting internally to get some clarity on the counts you should be
> expecting when using pagination, I wanted to share that while there's a
> maximum of about 3,200 statuses that you can retrieve for a given
> user_timeline (when under normal operating conditions), you'll find that
> statuses/home_timeline and statuses/friends_timeline do indeed have a
> maximum result set of around 800 tweets and have for some time. We'll be
> making sure the documentation is correct in this area where it's incorrect
> currently.
>
> Of course, all of these theoretical maximums have some variance as caches
> are re-aligned in the system. Sometimes you might find a little more
> available than these maximums. Sometimes a little less. Important to note
> that the total tweet count includes retweets, but some methods don't return
> retweets unless you explicitly request them with include_rts=true.
>
> Happy tweeting,
> Taylor

Reply via email to