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