Ditto PJB :-) On Mon, Jan 4, 2010 at 8:12 PM, PJB <pjbmancun...@gmail.com> wrote:
> > I think that's like asking someone: why do you eat food? But don't say > because it tastes good or nourishes you, because we already know > that! ;) > > You guys presumably set the 5000 ids per cursor limit by analyzing > your user base and noting that one could still obtain the social graph > for the vast majority of users with a single call. > > But this is a bit misleading. For analytics-based apps, who aim to do > near real-time analysis of relationships, the focus is typically on > consumer brands who have a far larger than average number of > relationships (e.g., 50k - 200k). > > This means that those apps are neck-deep in cursor-based stuff, and > quickly realize the existing drawbacks, including, in order of > significance: > > - Latency. Fetching ids for a user with 3000 friends is comparable > between the two calls. But as you increment past 5000, the speed > quickly peaks at a 5+x difference (I will include more benchmarks in a > short while). For example, fetching 80,000 friends via the get-all > method takes on average 3 seconds; it takes, on average, 15 seconds > with cursors. > > - Code complexity & elegance. I would say that there is a 3x increase > in code lines to account for cursors, from retrying failed cursors, to > caching to account for cursor slowness, to UI changes to coddle > impatient users. > > - Incomprehensibility. While there are obviously very good reasons > from Twitter's perspective (performance) to the cursor based model, > there really is no apparent obvious benefit to API users for the ids > calls. I would make the case that a large majority of API uses of the > ids calls need and require the entire social graph, not an incomplete > one. After all, we need to know what new relationships exist, but > also what old relationships have failed. To dole out the data in > drips and drabs is like serving a pint of beer in sippy cups. That is > to say: most users need the entire social graph, so what is the use > case, from an API user's perspective, of NOT maintaining at least one > means to quickly, reliably, and efficiently get it in a single call? > > - API Barriers to entry. Most of the aforementioned arguments are > obviously from an API user's perspective, but there's something, too, > for Twitter to consider. Namely, by increasing the complexity and > learning curve of particular API actions, you presumably further limit > the pool of developers who will engage with that API. That's probably > a bad thing. > > - Limits Twitter 2.0 app development. This, again, speaks to issues > bearing on speed and complexity, but I think it is important. The > first few apps in any given media or innovation invariably have to do > with basic functionality building blocks -- tweeting, following, > showing tweets. But the next wave almost always has to do with > measurement and analysis. By making such analysis more difficult, you > forestall the critically important ability for brands, and others, to > measure performance. > > - API users have requested it. Shouldn't, ultimately, the use case > for a particular API method simply be the fact that a number of API > developers have requested that it remain? > > > On Jan 4, 2:07 pm, Wilhelm Bierbaum <wilh...@twitter.com> wrote: > > Can everyone contribute their use case for this API method? I'm trying > > to fully understand the deficiencies of the cursor approach. > > > > Please don't include that cursors are slow or that they are charged > > against the rate limit, as those are known issues. > > > > Thanks. >
