Hi,

I also think that the main issue is not the amount of data, but the
number of API calls.

I vote for bulk API. It may be faster to implement for Twitter guys,
too.

= Oren

On Oct 23, 5:48 am, Harshad RJ <harshad...@gmail.com> wrote:
> Michael,
>
> On Fri, Oct 23, 2009 at 8:36 AM, Michael Steuer <mste...@gmail.com> wrote:
> > I don't see why the data size would make a difference.
>
> If you application needs the complete data, then it won't make a difference.
>
> But for applications that don't need it, it directly impacts bandwidth, and
> depending on the server architecture, it can impact cache hit-ratio, cache
> pressure, buffer quantity and buffer size. Similar considerations are on the
> client side, perhaps to a lesser degree.
>
> Also, on the server side, if lesser amount of data results in a fewer
> table-joins that could make a huge difference.
>
> This is all speculation on my side though and the best guys to know & decide
> are in Twitter.
>
> > I currently request the same amount of data in 100 calls of 1 user, as I
> > would in 1 call of 100 users. My application does require a little more info
> > than yours apparently, and I'm sure every app requires a different subset,
> > so a user object should remain a user object and return all info.
>
> I agree; I am hoping, with a big dose of optimism, that we (social-graph app
> developers and Twitter) can agree upon a common subset, and the ETA for this
> might be earlier than a bulk API with complete user data.
>
> --
> Harshad RJhttp://hrj.wikidot.com

Reply via email to