[twitter-dev] Re: Deprecation of the email parameter for users/show
The issue is marked as WontFix, but comment 71 mentions the existence of a closed beta. Any info on this? -- 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: Deprecation of the email parameter for users/show
If you are going to deprecate this method, can you at least return a user not found error as opposed to returning user twitter.com/show? I have received numerous complaints that users we lookup are being assigned to user show and their TonsOfWeed.com website -- which for obvious reasons is not the way to handle a deprecated function. - Todd On Apr 2, 9:00 pm, John Sampson j...@johnasampson.com wrote: Thank you for the clarity and for putting greater detail on the deprecation of user/show (find by email). I completely agree to Twitter wanting to protect its user's privacy. I'd like to think that the value created by whitelisted applications is far greater than the pain being caused by non-whitelisted api users. I hope that a speedy solution can be found for these spammers. Much of my concern I'd previously mentioned on ticket #353 -http://code.google.com/p/twitter-api/issues/detail?id=353#c8. To be clear, this does break the Twitter integration with our Firefox extension (which I consider the most valuable portion of our ext), surfacing information for user with screen name show rather than the person you are connecting with keyed off email. Additionally, workflow need be re-authored in our other apps that have leveraged this method to date. Hoping I can be of further assistance in returning this method to the production API. John Sampsonhttp://zentact.com On Apr 2, 5:59 pm, Doug Williams d...@twitter.com wrote: For a few days, the users/show method offered look up based on a user's email address. So short-lived was its documented availability that we removed it without much fanfare. This thread [1] has mention of this deprecation. Recently, there has been quite a bit of discussion on this feature's reinstatement on and off the list. Issue 353 [2] covers this request. The use of the method was largely as intended; people were discovering account connections based email addresses. This made integration with other networks and applications trivial. However, there was a significant amount of traffic that was using this parameter for evil. In either case, the adoption was minimal (we did not receive a complaint that the deprecation completely broke someone's application). The rationale for deprecation was to protect our users' privacy. We do realize the large amount of value that this parameter creates for application developers. However at this time, we are working to identify a solution for the spammers that caused the deprecation. One suggestion is to grant trusted applications access to this parameter. Since our answer to trusting applications is OAuth and it is still in beta, we will not be able to devote the resources necessary to bring this parameter back at this time. If you are developing an application that could benefit from an email-based lookup, please star the issue [2] accordingly. 1.http://groups.google.com/group/twitter-development-talk/browse_thread... 2.http://code.google.com/p/twitter-api/issues/detail?id=353 Thanks, Doug Williams Twitter API Supporthttp://twitter.com/dougw
[twitter-dev] Re: Deprecation of the email parameter for users/show
Seconding this. On Apr 3, 4:51 am, Todd Sampson toddsampson2...@gmail.com wrote: If you are going to deprecate this method, can you at least return a user not found error as opposed to returning user twitter.com/show? I have received numerous complaints that users we lookup are being assigned to user show and their TonsOfWeed.com website -- which for obvious reasons is not the way to handle a deprecated function. - Todd On Apr 2, 9:00 pm, John Sampson j...@johnasampson.com wrote: Thank you for the clarity and for putting greater detail on the deprecation of user/show (find by email). I completely agree to Twitter wanting to protect its user's privacy. I'd like to think that the value created by whitelisted applications is far greater than the pain being caused by non-whitelisted api users. I hope that a speedy solution can be found for these spammers. Much of my concern I'd previously mentioned on ticket #353 -http://code.google.com/p/twitter-api/issues/detail?id=353#c8. To be clear, this does break the Twitter integration with our Firefox extension (which I consider the most valuable portion of our ext), surfacing information for user with screen name show rather than the person you are connecting with keyed off email. Additionally, workflow need be re-authored in our other apps that have leveraged this method to date. Hoping I can be of further assistance in returning this method to the production API. John Sampsonhttp://zentact.com On Apr 2, 5:59 pm, Doug Williams d...@twitter.com wrote: For a few days, the users/show method offered look up based on a user's email address. So short-lived was its documented availability that we removed it without much fanfare. This thread [1] has mention of this deprecation. Recently, there has been quite a bit of discussion on this feature's reinstatement on and off the list. Issue 353 [2] covers this request. The use of the method was largely as intended; people were discovering account connections based email addresses. This made integration with other networks and applications trivial. However, there was a significant amount of traffic that was using this parameter for evil. In either case, the adoption was minimal (we did not receive a complaint that the deprecation completely broke someone's application). The rationale for deprecation was to protect our users' privacy. We do realize the large amount of value that this parameter creates for application developers. However at this time, we are working to identify a solution for the spammers that caused the deprecation. One suggestion is to grant trusted applications access to this parameter. Since our answer to trusting applications is OAuth and it is still in beta, we will not be able to devote the resources necessary to bring this parameter back at this time. If you are developing an application that could benefit from an email-based lookup, please star the issue [2] accordingly. 1.http://groups.google.com/group/twitter-development-talk/browse_thread... 2.http://code.google.com/p/twitter-api/issues/detail?id=353 Thanks, Doug Williams Twitter API Supporthttp://twitter.com/dougw
[twitter-dev] Re: Deprecation of the email parameter for users/show
Welcome the users/show returns data when no user is specified issue to the crew [1]. 1. http://code.google.com/p/twitter-api/issues/detail?id=416 Doug Williams Twitter API Support http://twitter.com/dougw On Fri, Apr 3, 2009 at 6:50 AM, Tim Rosenblatt trose...@gmail.com wrote: Seconding this. On Apr 3, 4:51 am, Todd Sampson toddsampson2...@gmail.com wrote: If you are going to deprecate this method, can you at least return a user not found error as opposed to returning user twitter.com/show? I have received numerous complaints that users we lookup are being assigned to user show and their TonsOfWeed.com website -- which for obvious reasons is not the way to handle a deprecated function. - Todd On Apr 2, 9:00 pm, John Sampson j...@johnasampson.com wrote: Thank you for the clarity and for putting greater detail on the deprecation of user/show (find by email). I completely agree to Twitter wanting to protect its user's privacy. I'd like to think that the value created by whitelisted applications is far greater than the pain being caused by non-whitelisted api users. I hope that a speedy solution can be found for these spammers. Much of my concern I'd previously mentioned on ticket #353 -http://code.google.com/p/twitter-api/issues/detail?id=353#c8. To be clear, this does break the Twitter integration with our Firefox extension (which I consider the most valuable portion of our ext), surfacing information for user with screen name show rather than the person you are connecting with keyed off email. Additionally, workflow need be re-authored in our other apps that have leveraged this method to date. Hoping I can be of further assistance in returning this method to the production API. John Sampsonhttp://zentact.com On Apr 2, 5:59 pm, Doug Williams d...@twitter.com wrote: For a few days, the users/show method offered look up based on a user's email address. So short-lived was its documented availability that we removed it without much fanfare. This thread [1] has mention of this deprecation. Recently, there has been quite a bit of discussion on this feature's reinstatement on and off the list. Issue 353 [2] covers this request. The use of the method was largely as intended; people were discovering account connections based email addresses. This made integration with other networks and applications trivial. However, there was a significant amount of traffic that was using this parameter for evil. In either case, the adoption was minimal (we did not receive a complaint that the deprecation completely broke someone's application). The rationale for deprecation was to protect our users' privacy. We do realize the large amount of value that this parameter creates for application developers. However at this time, we are working to identify a solution for the spammers that caused the deprecation. One suggestion is to grant trusted applications access to this parameter. Since our answer to trusting applications is OAuth and it is still in beta, we will not be able to devote the resources necessary to bring this parameter back at this time. If you are developing an application that could benefit from an email-based lookup, please star the issue [2] accordingly. 1.http://groups.google.com/group/twitter-development-talk/browse_thread... 2.http://code.google.com/p/twitter-api/issues/detail?id=353 Thanks, Doug Williams Twitter API Supporthttp://twitter.com/dougw
[twitter-dev] Re: Deprecation of the email parameter for users/show
Thank you for the clarity and for putting greater detail on the deprecation of user/show (find by email). I completely agree to Twitter wanting to protect its user's privacy. I'd like to think that the value created by whitelisted applications is far greater than the pain being caused by non-whitelisted api users. I hope that a speedy solution can be found for these spammers. Much of my concern I'd previously mentioned on ticket #353 - http://code.google.com/p/twitter-api/issues/detail?id=353#c8. To be clear, this does break the Twitter integration with our Firefox extension (which I consider the most valuable portion of our ext), surfacing information for user with screen name show rather than the person you are connecting with keyed off email. Additionally, workflow need be re-authored in our other apps that have leveraged this method to date. Hoping I can be of further assistance in returning this method to the production API. John Sampson http://zentact.com On Apr 2, 5:59 pm, Doug Williams d...@twitter.com wrote: For a few days, the users/show method offered look up based on a user's email address. So short-lived was its documented availability that we removed it without much fanfare. This thread [1] has mention of this deprecation. Recently, there has been quite a bit of discussion on this feature's reinstatement on and off the list. Issue 353 [2] covers this request. The use of the method was largely as intended; people were discovering account connections based email addresses. This made integration with other networks and applications trivial. However, there was a significant amount of traffic that was using this parameter for evil. In either case, the adoption was minimal (we did not receive a complaint that the deprecation completely broke someone's application). The rationale for deprecation was to protect our users' privacy. We do realize the large amount of value that this parameter creates for application developers. However at this time, we are working to identify a solution for the spammers that caused the deprecation. One suggestion is to grant trusted applications access to this parameter. Since our answer to trusting applications is OAuth and it is still in beta, we will not be able to devote the resources necessary to bring this parameter back at this time. If you are developing an application that could benefit from an email-based lookup, please star the issue [2] accordingly. 1.http://groups.google.com/group/twitter-development-talk/browse_thread... 2.http://code.google.com/p/twitter-api/issues/detail?id=353 Thanks, Doug Williams Twitter API Supporthttp://twitter.com/dougw
