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 >
