[Twisted-Python] Dropping support for old cred
![](https://secure.gravatar.com/avatar/7ed9784cbb1ba1ef75454034b3a8e6a1.jpg?s=120&d=mm&r=g)
The modules: twisted.cred.authorizer twisted.cred.identity twisted.cred.service twisted.cred.perspective constitute "classic cred", which has been deprecated for some time now. "New cred" is available in the modules: twisted.cred.portal twisted.cred.checkers twisted.cred.credentials and offers a vastly superior API. The only remaining code in Twisted which uses "classic cred" is the old PB log in method, which is also deprecated (in favor of one based around new cred), and the old application code (twisted.internet.app) which is also deprecated in favor of twisted.application. It would be nice to remove this code from the next Twisted release. Does anyone have any applications still relying on them which they plan to use with Twisted 2.1? If so, what is preventing you from updating the code to the new, vastly improved APIs? Jp & Itamar
![](https://secure.gravatar.com/avatar/fe24473d748a78f2ae29cdbc11c293a4.jpg?s=120&d=mm&r=g)
Jp Calderone wrote:
Our codebase at work still uses old cred. I've never had the time or customer requirement to do the upgrade. Unless I'd get a performance benefit out of it, it'd be hard to justify the time spent. On the other hand, perhaps I do not need Twisted 2.1 either. What do I stand to gain by making the switch? What benefit can I use to sell this? I assume that I could do this fairly incrementally as we have about 10 different processes that communicate within a server cluster over PB. I still use the old PB APIs too (so no PBClientFactory for me!). We still use the old application code as well for the same sorts of reasons. :) I don't think we have anything that relies on that though, we just use barebones tap files (more deprecated code!). - Bruce
![](https://secure.gravatar.com/avatar/d6328babd9f9a98ecc905e1ccac2495e.jpg?s=120&d=mm&r=g)
Bruce Mitchener wrote:
Jp Calderone wrote:
old->new cred would have zero performance benefit, I'd guess. Twisted 1.3->2.1 might have some but I don't believe anyone's measured it comprehensively yet. 1.3->2.1 with deprecations would almost certainly be a slowdown.
Given what I know about your application, upgrading to 2.1 wouldn't be a big win. At some point - if we are anywhere close to the "schedule" that I imagine, this would be around 2.2 - there will be several new protocols availble and you might want to upgrade to make use of those. The main advantage of new cred is that it gives a consistent view of login and session management across all protocols that your application supports. Right now the featureset is rather bare-bones, but I have plans to build upon the existing API and add features to support things like cross-protocol session management and authentication (e.g. automatic support for things like SMTP-after-POP authentication, but using any two protocols). Something like that would be totally impossible with old cred, since it barely even provides an abstraction for the same sorts of things that new cred does. At some point NewPB will arrive, too - and when that does, I believe that the upgrade in terms of performance and security will be well worth it. Talk to warner about when that might happen though, it's still a mystery to me :).
![](https://secure.gravatar.com/avatar/fe24473d748a78f2ae29cdbc11c293a4.jpg?s=120&d=mm&r=g)
Jp Calderone wrote:
Our codebase at work still uses old cred. I've never had the time or customer requirement to do the upgrade. Unless I'd get a performance benefit out of it, it'd be hard to justify the time spent. On the other hand, perhaps I do not need Twisted 2.1 either. What do I stand to gain by making the switch? What benefit can I use to sell this? I assume that I could do this fairly incrementally as we have about 10 different processes that communicate within a server cluster over PB. I still use the old PB APIs too (so no PBClientFactory for me!). We still use the old application code as well for the same sorts of reasons. :) I don't think we have anything that relies on that though, we just use barebones tap files (more deprecated code!). - Bruce
![](https://secure.gravatar.com/avatar/d6328babd9f9a98ecc905e1ccac2495e.jpg?s=120&d=mm&r=g)
Bruce Mitchener wrote:
Jp Calderone wrote:
old->new cred would have zero performance benefit, I'd guess. Twisted 1.3->2.1 might have some but I don't believe anyone's measured it comprehensively yet. 1.3->2.1 with deprecations would almost certainly be a slowdown.
Given what I know about your application, upgrading to 2.1 wouldn't be a big win. At some point - if we are anywhere close to the "schedule" that I imagine, this would be around 2.2 - there will be several new protocols availble and you might want to upgrade to make use of those. The main advantage of new cred is that it gives a consistent view of login and session management across all protocols that your application supports. Right now the featureset is rather bare-bones, but I have plans to build upon the existing API and add features to support things like cross-protocol session management and authentication (e.g. automatic support for things like SMTP-after-POP authentication, but using any two protocols). Something like that would be totally impossible with old cred, since it barely even provides an abstraction for the same sorts of things that new cred does. At some point NewPB will arrive, too - and when that does, I believe that the upgrade in terms of performance and security will be well worth it. Talk to warner about when that might happen though, it's still a mystery to me :).
participants (3)
-
Bruce Mitchener
-
Glyph Lefkowitz
-
Jp Calderone