Thanks, this makes sense (that api status fetching is modeling your cost this way).
J On Sep 1, 7:40 am, John Kalucki <j...@twitter.com> wrote: > Fetching a random list of statuses is likely to include a number of statuses > that are not in cache. I think accounting for them on a one-by-one basis > models our cost fairly well. > > -John Kaluckihttp://twitter.com/jkalucki > Twitter Inc. > > > > On Wed, Sep 1, 2010 at 8:00 AM, Jaanus <jaa...@gmail.com> wrote: > > The statuses/show/:id API method right now only retrieves a single > > status. Could we have a bulk version, where you can pass a set of > > status ID-s, and receive a set of statuses in return? Primary > > motivation is to conserve rate limit. In some apps, you have a set of > > status ID-s that you want to display to user, and fetching them one by > > one consumes limit like crazy. > > > J > > > -- > > Twitter developer documentation and resources:http://dev.twitter.com/doc > > API updates via Twitter:http://twitter.com/twitterapi > > Issues/Enhancements Tracker: > >http://code.google.com/p/twitter-api/issues/list > > Change your membership to this group: > >http://groups.google.com/group/twitter-development-talk?hl=en -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
