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 the http://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. > > see http://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-friend-graph/ 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
