Hey Dossy, This sounds awesome, and I'd be very tempted, however I've come up with a solution which should cater for any size of user account.
Right now when I periodically (~24 hours) note a set of changes to the social graph, I create an entry in a (persistent) ring buffer recording the new graph state. Previously, I wanted to use my existing uid->name cache and a bunch of API calls to resolve all the changes IDs in this entry. The solution is really simple. Instead if there are more id->name calls required than there is quota, I simply use up half the remaining quota resolving some names, and reschedule the graph check for 1 hours time rather than 24. The next check will pick up where the previous one left off doing resolution, until eventually the entire entry is resolved (and my cache is bigger for the future:). This also neatly breaks down the amount of work done for very large sets of changes into chunks of at most 35 (quota/2) HTTP requests per hour per user. David. On May 30, 11:28 pm, Dossy Shiobara <[email protected]> wrote: > On 5/30/09 3:46 PM, David W wrote: > > > [... David asks about bulk resolving of Twitter user IDs to screen_name ...] > > I don't know what the Twitter TOS says, but I've got a sizable cache of > (reasonably fresh) Twitter user data thanks to Twitter Karma. > > Would it be a Twitter TOS violation for me to publish an API to allow > bulk resolution of IDs to screen_name? Is this something that folks > would use if I made it available? > > -- > Dossy Shiobara | [email protected] |http://dossy.org/ > Panoptic Computer Network |http://panoptic.com/ > "He realized the fastest way to change is to laugh at your own > folly -- then you can let go and quickly move on." (p. 70)
