You can always provide your own cache. It doesn't take that much to get a complete name<->ID cache locally. What does take a lot of calls is keeping it up-to-date. Since you can change names on ID's it's not always accurate (though the ID never changes).
It's a huge task to get that initial scrape, takes about 2 months depending on your access, but it's doable. If we could make more calls per hour you could significantly cut that time, or if twitter made just that information available in a "fire- hose" format where you could suck down the entire list at once. It'll be a big file, there's almost 30 million user IDs now. On Mar 29, 4:38 pm, Jesse Stay <jesses...@gmail.com> wrote: > If Twitter's going to allow this, why don't they just do it themselves and > provide more accurate and up-to-date info? How often does this cache > update? I'm curious how accurate and reliable this would be, since people > are constantly modifying their social graph. > > Alex and crew have already said they might be able to provide more info once > they fully convert over to their new architecture. My hope is that once > they're able to do that I can just pull subsets of each social graph down, > such as "number of new followers since x date", or other criteria. A > FQL-type language (similar to Facebook's) would be ideal for something like > that. > > Jesse > > On Sun, Mar 29, 2009 at 1:03 PM, softprops <d.tang...@gmail.com> wrote: > > > Wow! What a great idea. Offloading the burden on twitter's servers/dbs > > to a simple id->name cache hosted via another service on someone > > elses. I will have to check that out. > > > On Mar 29, 2:52 pm, Damon Clinkscales <sca...@pobox.com> wrote: > > > On Sat, Mar 28, 2009 at 11:47 PM, Damon Clinkscales <sca...@pobox.com> > > wrote: > > > > see > > > > > On Sat, Mar 28, 2009 at 9:16 PM, softprops <d.tang...@gmail.com> > > wrote: > > > > >> It would be nice if thehttp:// > > twitter.com/[friends|followers]/ids.format > > > >> uri's could return a bit more useful info like the screen_name. > > > >> .... [ snip ] ... > > > >> <?xml version="1.0" encoding="UTF-8"?> > > > >> <ids> > > > >> <id screen_name="foo">1</id> > > > >> <id screen_name="bar">2</id> > > > >> </ids> > > > > > They aren't going to do this for performance reasons, even though yes, > > > > it would be useful. > > > > > seehttp://is.gd/ptJ9 > > > > > -damon > > > > An alternative solution may be possible though. > > > > I've recently been reminded that @infochimps has a "massive scrape of > > > the Twitter social graph" and is willing to make that available, in > > > whole or in part. However, they are currently awaiting Twitter's > > > permission on precisely what can be released. > > > > You can read more about this here -> > >http://blog.infochimps.org/2008/12/29/massive-scrape-of-twitters-frie... > > > > Assuming that the data is released, even in a limited form, there is > > > potential there for an id<-->screen_name mapping table which could > > > serve as a "cache primer" for apps that need that. This could > > > potentially save a bajillion calls against Twitter's API, which in > > > turn would have other good effects. One of the most notable places > > > where this is obviously needed is tying Twitter Search results to > > > Twitter users. For historical reasons, the user id in the search > > > result is not the Twitter user_id, so you have to use the screen name. > > > > -damon > > > --http://twitter.com/damon
