[twitter-dev] Re: Search API from_user_id doesn't match up with the proper Twitter user_id
Also, while it would be possible to use screen names for relations (i.e. from_user), this would have a very negative side effect. Mainly, if a user were to change their Twitter account name, previous relations would be lost. On Dec 22, 9:44 am, Corey Ballou ball...@gmail.com wrote: For clarification, I had intended to say from_user_id, as the username is returned properly. On Dec 22, 9:42 am, Corey Ballou ball...@gmail.com wrote: I just wanted to bring group-wide awareness to the fact that search results from Twitter do not return an actual user_id. This has been a known defect (and yes, I do believe it's a *very large* defect) going on over 2 years now. This is a call to arms to get this shit fixed. I can't believe it's marked as an enhancement. There's nobody else to blame for providing a return param of from_user that doesn't actually map to an actual user. For those of us storing relational data, you're costing precious API calls for those users who are still utilizing the search API. The streaming API is not sufficient for all use cases, so that's not a valid answer. Below is the direct link to the issue tracker. https://code.google.com/p/twitter-api/issues/detail?id=214 -- 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
[twitter-dev] Re: Search API from_user_id doesn't match up with the proper Twitter user_id
I'm sure I came off a little strong in the initial post; unfortunately for me google groups doesn't supply an edit button. I think there is still a grain of merit to the request to fix the issue, regardless of the API being free. I'm interest in knowing the trade-offs of Twitter essentially requiring third party apps to make subsequent calls to users/lookup for each unique user in a batch of results. The current problem I see, from Twitter's end, is that the subsequent call returns far more data than necessary. It's doubling the RTTs on both ends and creating an excessive amount of bandwidth for a trivial amount of data. I've got to imagine there's a number of cache misses going on due to the frequency of user updates and pulling the latest tweet, so it would seem rather costly. On Dec 22, 4:33 pm, Robbie Coleman rob...@robnrob.com wrote: I think twitter's response to this call to arms should be the HTTP Status Code: 420 - Chill ;-} -- 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
Re: [twitter-dev] Re: Search API from_user_id doesn't match up with the proper Twitter user_id
Yeah, well the call to arms may have been over the top. :) I agree that Twitter should fix the search API. Every time I ask, the answer is that it will be done eventually, and that it will have entities and everything else the streaming API has. I think this means that it will be the streaming API code with the ability to look backwards added. Think about it, isn't that what any architect would do? You combine your code bases. The real problem with search is its inability to go back beyond 5-7 days. Since Twitter plans to make its money from search ads and compete for Google ad revenue, more search results means more searching and more ad revenue. I bet they plan on an IPO within a year, and the story that Twitter search is just a tiny fraction of Google search but growing like crazy is exactly the type of promise that makes investors crazy for an IPO. It is also pretty sad that Google just added the ability to search millions of books going back 500 years, and Twitter only goes back 5 days! So search is clearly very important. I just don't think they want to fix this code. It is Summize code, and they show no interest in diving into it. Until they rewrite it, we have to wait. On Wed, Dec 22, 2010 at 8:55 PM, Corey Ballou ball...@gmail.com wrote: I'm sure I came off a little strong in the initial post; unfortunately for me google groups doesn't supply an edit button. I think there is still a grain of merit to the request to fix the issue, regardless of the API being free. I'm interest in knowing the trade-offs of Twitter essentially requiring third party apps to make subsequent calls to users/lookup for each unique user in a batch of results. The current problem I see, from Twitter's end, is that the subsequent call returns far more data than necessary. It's doubling the RTTs on both ends and creating an excessive amount of bandwidth for a trivial amount of data. I've got to imagine there's a number of cache misses going on due to the frequency of user updates and pulling the latest tweet, so it would seem rather costly. On Dec 22, 4:33 pm, Robbie Coleman rob...@robnrob.com wrote: I think twitter's response to this call to arms should be the HTTP Status Code: 420 - Chill ;-} -- 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 -- Adam Green Twitter API Consultant and Trainer http://140dev.com @140dev -- 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
