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.

Reply via email to