[twitter-dev] Re: Deprecation of source parameter registration
When you say that you can implicitly determine the application, does that mean that source parameters will become mandatory and anything posting via the API will be automatically assigned one? On Apr 8, 10:14 pm, Doug Williams wrote: > Applications wishing to append the "from [MyApp]" to tweets have > traditionally been able to register for a source parameter. This application > is then manually approved, and specified in a header parameter (named: > source) during the HTTP request. When OAuth is used for API authentication, > we can implicitly determine which application is updating on a user's > behalf. This allows us to use the application's name as the source parameter > and bypass the messy registration and authorization cycle. > > Beginning late this week or early next week, application developers will no > longer be able to request API source parameters. Instead, new source > parameters will only be available for OAuth applications, and will be > managed by the developer through the registration and management interface > (http://twitter.com/oauth_clients). > > Three key points: > 1) We ARE NOT deprecating Basic Authentication in the near term. We ARE > trying to reduce the API team's administrative load. > 2) We are trying to encourage OAuth adoption. > 3) Just for kicks, I'll restate #1: Basic Authentication will continue to > work as it currently does. Registered source parameters will continue to > work as they currently do. > > The FAQ [1] has been updated to reflect this change. > > 1.http://apiwiki.twitter.com/FAQ#HowdoIget%E2%80%9CfromMyApp%E2%80%9Dap... > > Thanks, > Doug Williams > Twitter API Supporthttp://twitter.com/dougw
[twitter-dev] Re: Deprecation of source parameter registration
Doug, What about applications that do not post through the API, but still want a source parameter? Or is this type of behavior going to be discouraged in the future? As an example, TweetStats does not require you log in to retrieve the data necessary, but I do have "promotional" links on the site that append the source parameter so it appears to come "from TweetStats". It's an extra bit of link juice (although I include a link in the tweet anyway, not all applications may) and it also allows me to get an idea of how many people use that link. Will this type of source specification still be allowed? Or in the future will I just need to sign up for OAuth and use that source parameter even if my application doesn't need auth? Thanks, dpc On Apr 8, 7:14 pm, Doug Williams wrote: > Applications wishing to append the "from [MyApp]" to tweets have > traditionally been able to register for a source parameter. This application > is then manually approved, and specified in a header parameter (named: > source) during the HTTP request. When OAuth is used for API authentication, > we can implicitly determine which application is updating on a user's > behalf. This allows us to use the application's name as the source parameter > and bypass the messy registration and authorization cycle. > > Beginning late this week or early next week, application developers will no > longer be able to request API source parameters. Instead, new source > parameters will only be available for OAuth applications, and will be > managed by the developer through the registration and management interface > (http://twitter.com/oauth_clients). > > Three key points: > 1) We ARE NOT deprecating Basic Authentication in the near term. We ARE > trying to reduce the API team's administrative load. > 2) We are trying to encourage OAuth adoption. > 3) Just for kicks, I'll restate #1: Basic Authentication will continue to > work as it currently does. Registered source parameters will continue to > work as they currently do. > > The FAQ [1] has been updated to reflect this change. > > 1.http://apiwiki.twitter.com/FAQ#HowdoIget%E2%80%9CfromMyApp%E2%80%9Dap... > > Thanks, > Doug Williams > Twitter API Supporthttp://twitter.com/dougw
[twitter-dev] Re: Deprecation of source parameter registration
We will certainly retain the administrative ability to create source parameters when circumstances warrant an exception. But on the whole, we will prefer that applications use OAuth to create and manage their communication with the site, even in the scenario you mentioned. Doug Williams Twitter API Support http://twitter.com/dougw On Wed, Apr 8, 2009 at 10:12 PM, Damon P. Cortesi wrote: > > Doug, > > What about applications that do not post through the API, but still > want a source parameter? Or is this type of behavior going to be > discouraged in the future? > > As an example, TweetStats does not require you log in to retrieve the > data necessary, but I do have "promotional" links on the site that > append the source parameter so it appears to come "from TweetStats". > It's an extra bit of link juice (although I include a link in the > tweet anyway, not all applications may) and it also allows me to get > an idea of how many people use that link. > > Will this type of source specification still be allowed? Or in the > future will I just need to sign up for OAuth and use that source > parameter even if my application doesn't need auth? > > Thanks, > > dpc > > On Apr 8, 7:14 pm, Doug Williams wrote: > > Applications wishing to append the "from [MyApp]" to tweets have > > traditionally been able to register for a source parameter. This > application > > is then manually approved, and specified in a header parameter (named: > > source) during the HTTP request. When OAuth is used for API > authentication, > > we can implicitly determine which application is updating on a user's > > behalf. This allows us to use the application's name as the source > parameter > > and bypass the messy registration and authorization cycle. > > > > Beginning late this week or early next week, application developers will > no > > longer be able to request API source parameters. Instead, new source > > parameters will only be available for OAuth applications, and will be > > managed by the developer through the registration and management > interface (http://twitter.com/oauth_clients). > > > > Three key points: > > 1) We ARE NOT deprecating Basic Authentication in the near term. We ARE > > trying to reduce the API team's administrative load. > > 2) We are trying to encourage OAuth adoption. > > 3) Just for kicks, I'll restate #1: Basic Authentication will continue to > > work as it currently does. Registered source parameters will continue to > > work as they currently do. > > > > The FAQ [1] has been updated to reflect this change. > > > > 1.http://apiwiki.twitter.com/FAQ#HowdoIget%E2%80%9CfromMyApp%E2%80%9Dap. > .. > > > > Thanks, > > Doug Williams > > Twitter API Supporthttp://twitter.com/dougw >
[twitter-dev] Re: Deprecation of source parameter registration
When I discovered that Twitter used the name from my recetly created app via OAuth, I was pleased. While the turn-around time for manual approval was great, I think that using the data which we've already supplied through the creation of a new OAuth app is the right way to go. Keep up the good work.
[twitter-dev] Re: Deprecation of source parameter registration
Why are you deprecating a very important feature for the basic auth method while your OAuth support is still in beta? The last official statement I read about Twitter and OAuth was that it went public, but is still considered beta. Also, if I did not miss an announcement, you were not yet encouraging developers to release OAuth based stuff - has this changed? 2009/4/9 Mobasoft > > When I discovered that Twitter used the name from my recetly created > app via OAuth, I was pleased. > While the turn-around time for manual approval was great, I think that > using the data which we've already supplied through the creation of a > new OAuth app is the right way to go. > > Keep up the good work. > >
[twitter-dev] Re: Deprecation of source parameter registration
Marco, OAuth is still in public beta. We are growing comfortable with the software's abilty and even see early OAuth inclusion in consumer facing sites. Nothing has changed in our stance toward driving releases because we are still planning some UX improvements. However we all write software because we want users to enjoy our work and understand that some developers have OAuth-based applications ready to ship and support. There is still time to get a source parameter through the manual registration process so developers that see the need should register now. We do not anticipate the layover from deprecation to the full release of OAuth to be very large which makes us confident that this deprecation is a safe move. Doug Williams Twitter API Support http://twitter.com/dougw On Thu, Apr 9, 2009 at 5:53 AM, Marco Kaiser wrote: > Why are you deprecating a very important feature for the basic auth method > while your OAuth support is still in beta? > > The last official statement I read about Twitter and OAuth was that it went > public, but is still considered beta. Also, if I did not miss an > announcement, you were not yet encouraging developers to release OAuth based > stuff - has this changed? > > > > 2009/4/9 Mobasoft > > >> When I discovered that Twitter used the name from my recetly created >> app via OAuth, I was pleased. >> While the turn-around time for manual approval was great, I think that >> using the data which we've already supplied through the creation of a >> new OAuth app is the right way to go. >> >> Keep up the good work. >> >> >
[twitter-dev] Re: Deprecation of source parameter registration
On a personal note, even though I have created a few "toy" apps that use OAuth to get a feel for it, I am holding off integrating OAuth into several of my longstanding apps until the last possible minute b/c of the current Beta instabilities (tho few, they still exist), and the recent twitter server availability issues. For Basic Auth stuff, down time or time-outs are fairly tolerable and just involve a retry of the request. For OAuth stuff, having a time-out or connection blip in the middle of the token transaction process wreaks havoc on the process flow and UX for the user and interacting with an app (which has happened to me more than a few times). > We do not anticipate the layover from deprecation to the full release of > OAuth to be very > large Does that mean you have a roadmap or estimated timeframe for taking OAuth out of Beta and into "full production mode"? I think it would be helpful for all involved to be clued into such information. -Chad On Thu, Apr 9, 2009 at 1:01 PM, Doug Williams wrote: > Marco, > OAuth is still in public beta. We are growing comfortable with the > software's abilty and even see early OAuth inclusion in consumer facing > sites. Nothing has changed in our stance toward driving releases because we > are still planning some UX improvements. However we all write software > because we want users to enjoy our work and understand that some developers > have OAuth-based applications ready to ship and support. > > There is still time to get a source parameter through the manual > registration process so developers that see the need should register now. We > do not anticipate the layover from deprecation to the full release of OAuth > to be very large which makes us confident that this deprecation is a safe > move. > > Doug Williams > Twitter API Support > http://twitter.com/dougw > > > On Thu, Apr 9, 2009 at 5:53 AM, Marco Kaiser wrote: >> >> Why are you deprecating a very important feature for the basic auth method >> while your OAuth support is still in beta? >> >> The last official statement I read about Twitter and OAuth was that it >> went public, but is still considered beta. Also, if I did not miss an >> announcement, you were not yet encouraging developers to release OAuth based >> stuff - has this changed? >> >> >> >> 2009/4/9 Mobasoft >>> >>> When I discovered that Twitter used the name from my recetly created >>> app via OAuth, I was pleased. >>> While the turn-around time for manual approval was great, I think that >>> using the data which we've already supplied through the creation of a >>> new OAuth app is the right way to go. >>> >>> Keep up the good work. >>> >> > >
[twitter-dev] Re: Deprecation of source parameter registration
Hi Doug, On Apr 9, 4:14 am, Doug Williams wrote: > > Beginning late this week or early next week, application developers will no > longer be able to request API source parameters. Instead, new source > parameters will only be available for OAuth applications, and will be > managed by the developer through the registration and management interface > (http://twitter.com/oauth_clients). This seems a little premature don't you think? The source parameter is important for marketing applications as well as gauging popularity - OAuth is both still in beta and unsupported by many clients/ applications. I've just started developing a Twitter app using python-twitter that is to run on Google AppEngine, but it will be some time after the next release before we have OAuth support (and even then it's dependent on a "major overhaul of the HTTP layer")[1]. Sam 1. http://code.google.com/p/python-twitter/issues/detail?id=37&q=oauth#c4
[twitter-dev] Re: Deprecation of source parameter registration
We've finished the removal of this functionality from the site so third-party registration is no longer supported. If you feel that you have an extraordinary need for explicit source parameter registration, please email a...@twitter.com. Include why you need to register an application manually and why OAuth will not work in your case. Thanks, Doug Williams Twitter API Support http://twitter.com/dougw On Apr 12, 7:39 am, Sam Johnston wrote: > Hi Doug, > > On Apr 9, 4:14 am, Doug Williams wrote: > > > > > Beginning late this week or early next week, application developers will no > > longer be able to request APIsourceparameters. Instead, newsource > > parameters will only be available for OAuth applications, and will be > > managed by the developer through the registration and management interface > > (http://twitter.com/oauth_clients). > > This seems a little premature don't you think? Thesourceparameter is > important for marketing applications as well as gauging popularity - > OAuth is both still in beta and unsupported by many clients/ > applications. > > I've just started developing a Twitter app using python-twitter that > is to run on Google AppEngine, but it will be some time after the next > release before we have OAuth support (and even then it's dependent on > a "major overhaul of the HTTP layer")[1]. > > Sam > > 1.http://code.google.com/p/python-twitter/issues/detail?id=37&q=oauth#c4